Who holds the accounts behind your website, and how to move any of them
Five layers sit behind a website. Which ones we manage and why, what our terms guarantee about getting any of them back, and what to ask any supplier.
The short answer
Five layers sit behind a website: the domain, the DNS, the hosting project, the code repository and the analytics. Each one has an account holder, and they do not have to be the same party. Your domain is registered in your company’s name, in every arrangement, with us listed as the administrator rather than the holder. Your analytics property is in your name as well, inside an account we manage. The repository, the hosting project and the DNS zone are managed in our accounts, because one place is faster and safer to operate than one account per client. Holding a layer yourself is the strongest position, and where you want that, you get it. Where you do not, two things have to be checkable: that the layer moves to you on request, and that access is never withheld over a disagreement. Both are in our terms.
The five layers, and the question to ask about each
| Layer | What it is | The question to ask any supplier |
|---|---|---|
| Domain | The name everything points at, held at a registrar | Who is the registrant, and are the transfer lock and auto-renew on? Ours: you are, always. |
| DNS | The records that route the site, the mail and the certificates | Whose account is the zone in, and can I have an export of the records today? |
| Hosting project | The platform account the site builds and runs in | Whose account, and what does moving it to mine involve? |
| Repository | The code and its full history | Whose organisation holds it, and am I a member with admin rights? |
| Analytics | The property that holds the measurement history | Who owns the property, and is the history transferable or does it restart? Ours: the property is in your name, in an account we manage. |
Why one account is faster to operate
- One set of access rules. People join and leave. Removing someone from one organisation is one action; removing them from a separate account per client is one chance to miss one for every client.
- One place where the work happens. Deployments, previews, alerts and logs sit together, which is what makes a two-minute fix a two-minute fix instead of a login hunt.
- Security you can actually keep up. Two-factor enforcement, hardware keys and access reviews applied once to one organisation beat the same policy promised across many accounts nobody audits.
- Your analytics stay yours to read. The property is in your name, and you can see your own statistics on our site.
- It is a practical choice, not a principle. It is faster for us and it is what we default to. It is not a rule, and a client who wants a layer in their own name gets it.
What makes it safe, and it is in the contract
An arrangement can change without you. A clause cannot. Our terms therefore say, in the clause about late payment and disputes, that 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.
That is the sentence to look for at any supplier, including us. It is stronger than the name on an account, because a name can move quietly and a clause has to be renegotiated in front of you.
How the money works
There is no margin on hosting in our model, which is also why we can recommend whatever fits your case best rather than whatever pays best. Where an account is in your name, the provider bills you directly at their published price. Where a project sits in one of our accounts, you can ask what the provider charges and we tell you. We are paid for maintenance, support and development, with the scope attached.
What this means for you
Go through the five layers once and write down, per layer, who the account holder is. You will probably not know all five, and that is the finding. Then ask your supplier for one sentence in writing: every layer moves to your name on request, and access is never withheld over a disagreement. Start with the domain, because it is the layer everything else depends on and the slowest one to recover when it goes wrong.
Frequently asked questions
Is it not more convenient if the supplier handles all the accounts?
It is convenient, and that is exactly why it happens. One place to operate from is faster: one set of access rules, one place where deployments and alerts live, one account to keep secure properly. The risk is not the convenience. The risk is the sentence that is usually missing next to it: what happens to this account if you leave, and who decides. Ask for that sentence in writing before you worry about whose name is on the account, because the name without the sentence protects nobody.
Who pays the provider, and can I see what it really costs?
Where the account is yours, the provider bills you directly at their published price and you see every line. Where the project sits in one of our accounts, you can ask what the provider charges for it and we tell you, because there is no margin on hosting in our model; we are paid for the work, not for standing between you and a platform. If you would rather have the account in your own name and the invoice in your own billing, say so and we move it.
Does this apply to the domain too?
Especially the domain, and here the answer is short: it is registered in your company's name, always. We are listed as the administrative contact so we can change records and renew on time, and that is a different thing from being the holder. Holding someone else's domain means carrying responsibility for their website, and that is not ours to carry. Check yours anyway, at any supplier: who the registrant is, whether auto-renew and the transfer lock are on, and whether the billing card is still valid.