The single most common call we take does not start with a technical question. It starts with a sentence like this:
The person who built it stopped replying.
What follows is always some version of the same inventory. There is a site, and it works, mostly. Nobody knows the hosting password. The domain renewal notice goes to an email address at a company that no longer exists. The code is on a laptop somewhere. Somebody has an admin login that lets them change text but not prices. And every question about what would happen if you touched anything ends in a shrug.
This is rarely malice. Most of the time it is a builder who registered everything on their own account because it was faster on the day, meant to sort it out later, and then simply moved on. The result is identical either way: you have paid in full for something you cannot leave, cannot move, and cannot hand to anybody else.
It is also completely preventable, in about an hour, before the final invoice clears. Here is the list.
Group one: the name on the door
1. The domain registration
The registrant on the domain record should be your business, with a billing email your business controls permanently. Not your developer’s Gmail. Not an agency account. You should be able to log into the registrar yourself today and see the renewal date.
This is the one that turns a disagreement into a hostage situation, because it is the only item on this list you genuinely cannot rebuild. Everything else can be recreated with time and money. Your domain cannot.
2. DNS control
Separate from the registration, and frequently held somewhere else entirely. Whoever controls DNS controls where your website and your company email actually point, regardless of whose name is on the domain. You want admin access to that account, not a promise that someone will make changes for you.
3. Email routing and SSL
Check where your company email is administered and who holds the certificate for the site. Both tend to be set up once during launch week and never thought about again until the morning they expire and your email stops arriving.
Group two: the code
4. The repository, with its history
The code should live in a repository your business owns, with the full commit history intact. A zip file emailed at handover is not this. History is the difference between a codebase somebody can pick up and one somebody has to reverse engineer, because it is the only record of why anything was done the way it was.
5. Instructions to build and deploy it
A short written document explaining how to run the project, what it depends on, and how a change gets from a laptop to the live site. If this exists only in a person’s head, you own the code but not the ability to use it.
6. Environment variables and secrets
The API keys, database credentials and service tokens the site needs to run, listed and handed over deliberately. This is the item most often missed, and it is the one that stops a new developer dead on their first day.
7. Licences for anything bought
Themes, plugins, fonts, stock photography, paid components. Each should be licensed to your business rather than to your builder’s account. Font licensing in particular is quietly one of the most common ways a small business ends up technically in breach of a contract it has never read.
Group three: where it runs
8. Hosting and server access
The hosting account in your business name, paid on your card, with you as an administrator. Being a user on somebody else’s account is not ownership, it is a courtesy that can be withdrawn.
9. The database, and a backup you have actually seen
Ask where the database lives, who can reach it, and how often it is backed up. Then ask for a copy of a recent backup. A backup nobody has ever restored or even downloaded is a belief, not a safety net.
10. The deployment pipeline
If changes go live automatically when code is updated, that automation runs somewhere, under someone’s account, holding credentials to your production system. You want to know where, and to be an owner on it.
Group four: everything bolted on
11. Third-party services
Payment gateway, transactional email, maps, file storage or CDN, chat widget, whatever else is wired in. Each is a separate account, each is billed to somebody, and each was very likely created with whichever email was closest to hand on the day. Get a list. Get admin on each one.
12. Analytics, search and social
Google Analytics, Search Console, the business profile, ad accounts, and any pixels embedded in the pages. These hold your historical data, which is the one asset that genuinely cannot be regenerated. Lose access and you lose every year of traffic history you have accumulated.
The one-sentence test
If the checklist feels like a lot, collapse it into a single question and put it to whoever built your site:
Could a competent stranger take this over next week, without calling you?
A good builder answers yes immediately and offers to prove it. That answer costs them nothing, because a clean handover was never the thing keeping you around. The work was.
Watch for the answer that arrives dressed as helpfulness. Do not worry, we handle all of that for you is not a yes. It is a description of the exact position you are trying to avoid being in.
If you are already locked out
Most people read this list after the fact rather than before. It is still recoverable, and it is worth doing in this order.
- Look up your own domain. A public WHOIS lookup will show you the registrar and often the registrant organisation. That tells you which company to contact and how bad the situation actually is.
- Ask plainly and in writing. A short, unemotional email requesting transfer of the domain, hosting and code works more often than people expect. Most former builders are indifferent rather than hostile, and indifference responds to a clear, easy ask.
- Rebuild what is cheap to rebuild. A five page site is often faster to rebuild cleanly than to extract from an uncooperative host. Spend your effort recovering the things that are genuinely irreplaceable: the domain, the customer data, the analytics history.
- Fix the pattern, not just the incident. Whatever you build next, run this checklist before the final payment. The leverage exists exactly once, and it is the week before that invoice is settled.
Put it in the proposal, not the argument
The most useful thing you can do is make ownership a written line in the scope rather than a conversation you have when things have already gone wrong. One sentence is enough: all domains, hosting, repositories and third-party accounts will be registered to the client, with the client as owner, before final payment.
Any builder worth hiring will agree without hesitating, because for them it is a five-minute administrative task. The reaction to that sentence tells you more about the next two years than the portfolio did.
For what it is worth, this is how we work by default. Code, hosting, domains and third-party accounts go into your name from day one, which means leaving us is a permissions change rather than a negotiation. We think that is the only arrangement that makes the ongoing relationship honest: you should stay because the work is good, not because going is difficult.
Not sure what you actually own?
Send us your domain and we will tell you, in one reply, who the registrar thinks owns it and what else we can see from the outside. No charge, no obligation. If everything is in order we will say so and you can get on with your day.
Book a free 30-minute call and bring whatever access details you have. Even a half-remembered login is a starting point.