Here is a question most business owners cannot answer without making a phone call:
If your web developer stopped replying tomorrow, could you still change your own website?
Not "would it be difficult". Could you. Is there an account you can log into, a place the code lives that you can reach, a domain registration with your name on it.
For a large share of small and mid-sized businesses the honest answer is no, and they do not find out until the relationship ends — a developer moves on, an agency folds, a freelancer stops answering. What follows is not a technical problem. It is a hostage negotiation in which nobody set out to take a hostage.
Ownership is not a document. It is a list of accounts. Here is the list.
The nine accounts
Work through these on your own site. For each one, answer two questions: whose name and email is on the account, and can you log in right now without asking anyone.
1. The domain
The single most important item, and the one most often wrong. Your domain should be registered to your company, at a registrar where you hold the login, paid with your card, with auto-renew on.
A domain registered under your agency's account is the whole business held on someone else's lease. Everything — your website, your email, your links, ten years of search history — depends on a renewal you cannot make.
2. DNS
Sometimes at the registrar, sometimes elsewhere, and it is the switchboard: where your site is hosted, where your mail goes, which services can prove they are you. Losing access to DNS means you cannot move host, and cannot fix mail delivery.
3. Hosting
The server or platform the site runs on. Your account, your billing. "It's on our server" is a normal arrangement and a completely reasonable service — but know that it is a service you are renting, and ask what the exit looks like before you need one.
4. The code repository
The actual source of your website, with its full history. It should be in your organization on GitHub or GitLab, with your developer invited as a member — not the other way around.
This is the difference between hiring someone to build on your land and living in a house they own. Both can be perfectly happy. Only one of them lets you change builder.
5. The CMS or admin panel
The place you edit content. You should have an administrator account, not an editor account created for you by someone who kept the administrator seat.
6. Analytics
Your traffic history is a business asset, and it is not portable — you cannot backfill it into a new property. An analytics account owned by an agency means that on the day you leave, your historical data leaves with them.
7. Email
Separate from hosting, often forgotten until a migration breaks it. Own the mail accounts and the authentication records.
8. Design files
The editable source — Figma files, not exported images. Without them, every future change to a layout, a color or an icon starts by recreating what you already paid for.
9. Store and developer accounts
If there is an app, the Apple and Google developer accounts must be yours, with the signing keys handed over. An app published from an agency's account is an app you cannot update without them, and it is the purest lock-in available in software. We go into it further in you probably do not need a mobile app.
For a store, add the payment gateway and the merchant account to the list, for the same reason.
The lock-in patterns, and which are actually malicious
Most lock-in is not a scheme. It is a series of small conveniences that compound. It helps to tell them apart.
Accidental: the agency registered the domain because it was faster. Extremely common, almost never malicious, and trivially fixed by a transfer — if you ask before the relationship sours.
Structural: the site is on a proprietary platform. Page builders, closed CMS products, "our custom platform". The work exists but cannot leave. You are not being held hostage; you bought something that does not travel. The cost is real and it appears only when you try to move. See the case against your page builder.
Practical: nobody but the author can read the code. No documentation, no deployment instructions, conventions invented and unexplained. The result is the same as lock-in even though nothing was locked.
We met the extreme version of this at WClinic, a clinic network in Saint Petersburg. The legacy site had no documented way to deploy it at all — the knowledge of how to put a change live had simply left with whoever had it. Before any feature work, the environment had to be reconstructed, containerized, and moved into Git with a build pipeline. Nobody had done anything wrong on purpose. The company still could not change its own website.
Deliberate: access is the product. Hosting priced so leaving costs more than staying, refusal to hand over source, "the code is our intellectual property". This is the rarest and the only one that is a red flag about the supplier rather than about the setup.
On that last one, be precise about what is negotiable. A studio reusing its own internal libraries across clients is normal and fine. Your site, your content, your data and your configuration are yours. If a supplier will not commit to that in writing, that is the answer to the question you were asking.
The audit, as a table you can fill in
Print this. One row per account. Do not fill it in from memory — log in.
| Account | Whose name | Can you log in today | Who else has access |
|---|---|---|---|
| Domain registrar | |||
| DNS | |||
| Hosting | |||
| Code repository | |||
| CMS / admin | |||
| Analytics | |||
| Design files | |||
| App / payment accounts |
Two columns matter more than the others. If "whose name" is not your company on the first three rows, fix those first. If "can you log in today" is no anywhere, that row is a single point of failure sitting in someone else's inbox.
How to fix it without a fight
The overwhelming majority of these conversations are easy, because the other side never intended lock-in. Make it administrative rather than adversarial.
Ask in writing, and give a reason that is not about trust. "We are tidying up our business accounts for our accountant — can you move the domain into our registrar account and add us as owner on hosting and analytics?" Nobody argues with bookkeeping.
Do them in order of consequence. Domain and DNS first, because everything depends on them. Then repository and hosting. Then analytics, CMS, design files.
Do not transfer the domain on a Friday, and do not move it in the same week as a hosting migration. One change at a time, with mail tested after each.
Get the deployment written down. Access to the code is not the same as the ability to put a change live. Ask for a short document: how to run it locally, how to deploy, where the environment variables live, what external services it depends on.
If a supplier refuses all of it, you have learned something valuable while you still have a working website — which is a much better time to learn it than later.
What we commit to
This is one of the five things we put on the services page as a promise rather than a feature.
You own everything, from day one. Source in your Git organization. Editable design files. Your cloud accounts, your domain, your analytics. Mobile builds released under your Apple and Google developer accounts, with the signing keys handed to you.
No lock-in, ever. After the included support period, maintenance is $39 a month or nothing. Take the code and go elsewhere — it is yours either way, with no licence to renew and no exit fee. As we put it on the site: staying is a monthly choice, not something we engineered you into needing.
We are aware this is easy to write and easy to claim. So judge it the way you should judge any supplier: ask for the handover list before you sign, not after. Anyone who means it will have one ready. We keep ours in the handover checklist.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
My developer registered the domain and they have been great for years. Is this urgent?
Not urgent, and not a judgment on them. It is a single-person dependency on an asset your whole business runs through. Move it while everyone is happy — the transfer takes twenty minutes and removes a risk that has nothing to do with anybody's good intentions.
Is it normal for an agency to host the site?
Yes, and it can be a genuinely good deal. What is not normal is being unable to see the bill, unable to get a copy of the site, or facing a price to leave. Renting is fine. Renting without an exit is not.
Can a developer legally keep my source code?
It depends entirely on what you agreed, which is why the agreement should say it explicitly. Get one sentence in writing before work starts: on final payment, all source code, assets and accounts transfer to you. Ambiguity here is resolved slowly and expensively.
What if I have lost access and the developer is gone?
Recoverable in most cases, unpleasant in all of them. Registrars have dispute processes for domains registered on your behalf. Hosting companies will often help if you can prove you pay the bill. The code may be gone, which sometimes means rebuilding — do the ownership work on the new site before anything else.
We are a small business. Is this really worth an afternoon?
It is probably the highest-value afternoon available to you on this subject. Everything else in web is about getting more from the site you have. This is about continuing to have it.
