Your developer should not own your domain
A business calls a new developer to make a change to their website. The developer asks for access to the domain registrar. Nobody at the business has ever logged in to it. The account is registered to a personal email address belonging to someone who built the site four years ago and no longer replies.
We have watched this happen more than once. It is entirely avoidable, and it is worth half an hour of your time this week to check.
Why it happens
Rarely through malice. It is usually convenience at the start of a project. The developer already has a registrar account, setting up a new one for the client means paperwork and a card, and everyone wants to get on with the actual work. So it goes on the developer's account "for now".
"For now" then lasts as long as the domain does.
What it costs when it goes wrong
Your domain is the address of your business and, more importantly, it is where your email lives. Losing control of it is not a website problem, it is a communications problem. Email stops. Password resets for every other service you own go to an address you cannot access. Recovering a domain from an unresponsive registrant is slow, sometimes expensive, and sometimes genuinely not possible.
The website can be rebuilt in a few weeks. The domain and the email on it usually cannot be replaced at all.
What to check
Go through this list for your own organisation. Each item should be registered to an address your organisation controls, and someone in the organisation — not only a vendor — should be able to log in today.
- Domain registrar. Who is the registrant? Which email receives renewal notices? Is auto-renew on?
- DNS. Whoever controls DNS controls where your traffic and your email actually go, even if the domain itself is in your name.
- Hosting and cloud accounts. Billed to your organisation, not to a vendor who invoices you for it.
- Email service. The administrator account, not just a user account.
- App store accounts. Publisher accounts should belong to the company. Transferring a published app between accounts is painful.
- Analytics, payment gateway, SSL, source code repository. Same principle throughout.
- The code itself. Written into the contract as yours, in a repository you can access.
Use a role address, not a person
One detail that matters more than it looks: register everything to a role
address such as admin@yourcompany.com, not to an individual's
personal or work email.
People change jobs. When accounts are tied to a departed employee's personal address you get a slower version of the same problem, and it is just as awkward to unwind.
How we handle it
We create every account in the client's name and on the client's billing at the start of the project, and give them administrator access immediately. We hold access as a collaborator, at whatever level the work requires, which can be revoked by the client at any time without breaking anything they own.
It is slightly more setup work in week one. It also means that if a client decides to stop working with us, they change one permission and everything continues to run. We think a client should be able to leave easily. It is the only version of staying that means anything.
If you are not sure what state your own accounts are in, we will happily walk through the checklist with you. That is not a paid engagement, it is a phone call.