Ownership first: why you should own your domain, hosting and code
Domain, hosting, code and data belong in your name from day one. Why that matters, how it goes wrong, and how to fix it if it already has.
Our position, stated plainly
The four things
| What | Where it lives | Whose name must be on it |
|---|---|---|
| Domain | Registrar | Your company, your billing details, your two-factor device |
| DNS and hosting | DNS provider, hosting platform | Your company’s account; partner has a role inside it |
| Source code | Repository host | Your organisation; partner is a collaborator |
| Analytics and data | Analytics property, form data, databases | Your company as owner; partner has access |
If any of the four is in a supplier’s name, that supplier can, by accident or by intent, take your website or email offline, or make leaving them cost a rebuild.
How it goes wrong
Almost never through bad intent. The common story: an agency registers the domain “to make it easy”, hosts the site on their own account “because we get a better rate”, and keeps the code in their repository “because that is where our tooling is”. Every step was helpful. Then the agency is acquired, or the account manager leaves, or there is a dispute over an invoice, or the agency simply closes.
What “in your name” means in practice
- Domain. Your company is the registrant, the account is yours, the renewal card is yours and will not expire, two-factor is on a device you control. Your partner may be a technical contact.
- DNS and hosting. The account belongs to your organisation. Your partner has a role that lets them do the work, and you can revoke it. Billing goes to you, even if your partner manages it.
- Code. The repository sits under your organisation. Your partner is a collaborator. The build and deployment settings are documented and reproducible.
- Data. Analytics properties are owned by your company. Form submissions, customer records and databases are in accounts you can access without the partner.
Fixing it when it already went wrong
- Write down the current state. Four items, whose name, which email, which billing.
- Start with the domain. Ask for a transfer to a registrar account in your name. This is the item that can take everything offline.
- Move hosting and DNS to your accounts. Create the accounts yourself, invite the supplier, and migrate with a checklist so email does not break.
- Get the code. A transfer of the repository to your organisation, or a full copy including build configuration, plus a document on how to deploy it.
- Claim the data. Ownership of analytics properties, exports of form data and customer records, credentials for databases.
- Then renegotiate or leave. From a position where you can.
Why we are strict about it
It protects you, obviously. It also protects us. We never want to be the reason a client’s business is offline, and we never want a commercial disagreement to have anything to do with whether a website keeps running. Some layers sit in our accounts because one place is faster to operate, so we wrote the guarantee into our terms instead: deliverables already in production, and your access to the domain, DNS, hosting, repository and analytics, are never withheld and are transferred on request regardless of any dispute.
What this means for you
Spend one hour this week finding out whose name is on your domain, hosting, code and data. If it is all yours, you are in a better position than most businesses we meet. If it is not, fix it in the order above, while everyone is still friendly.
Frequently asked questions
Our agency registered our domain years ago. Is that a problem?
It is a risk, not yet a problem. Ask them to transfer the domain to a registrar account in your company's name, with your billing details and two-factor authentication. A cooperative agency does this in a week. Resistance tells you something.
Isn't it easier to let the supplier handle all accounts?
Easier on day one, and the source of some of the worst weeks we have seen. The supplier can still do all the work inside your accounts. The only difference is who can remove whom. That difference matters exactly once, and then it matters completely.
What about the tools the supplier pays for on our behalf?
Fine for genuinely shared tooling, as long as nothing your business depends on lives only there. The rule of thumb: if the supplier's credit card being declined could take your website or email offline, that account belongs in your name.
How do I check what is in whose name today?
Check the registrant of your domain in your registrar account, or ask whoever registered it, log in to the DNS and hosting accounts and check the owner and billing email, open the code repository and check the organisation, and check who is the owner of your analytics property. Write the four answers down. That page is the start of fixing it.