What “we will hand over the code” should actually mean
Most businesses discover what they do not own about their website at the worst moment: when they want to leave.
Owning a website means holding the domain, the hosting account, the code repository and the ability to rebuild and deploy the site without the agency that made it. Most handovers transfer files and nothing else, which leaves a business able to see its site but unable to change or move it.
Key takeaways
- A copy of the files is not ownership. Ownership is the domain, the hosting, the repository and a build you can run.
- The domain should be registered to your company, in an account you control, from day one.
- Ask for the handover terms before commissioning, because afterwards you have nothing to trade.
- A site you cannot rebuild from source is a site you cannot safely change.
- The test of a good handover is whether a different developer could take it on without contacting the first.
Where this goes wrong, and when people find out
Almost nobody asks about ownership when commissioning a website. The conversation is about design, pages and price, and the assumption is that having paid for something means owning it. That assumption holds for a sofa and not for software.
The discovery usually comes later, triggered by something ordinary: the agency becomes unresponsive, a price rises, a relationship ends, or somebody simply wants a different developer to make a change. At that point the business asks for its website and learns what it actually has. Often that is a login to a content system on somebody else's hosting, with the domain registered to the agency, no repository, and no way to produce a working copy of the site anywhere else.
None of that requires bad intent. It is the default outcome of nobody specifying otherwise, which is precisely why it is worth specifying at the start, while you are still the one choosing.
There is a version of this that is nobody's fault at all, and it is the most common one. A small business asks a freelancer to put up a site quickly. The freelancer registers the domain on their own account because it is faster than setting up a new one, builds on their own hosting because they already have it, and does an entirely good job. Three years later they have moved on, the business has grown, and an arrangement that was sensible for a weekend project is now the thing standing between a company and its own website.
The four things that together constitute ownership
It helps to be concrete, because ownership is not one thing and a handover can transfer some parts while quietly keeping others.
Two of these are accounts and two are artefacts, and the distinction is useful. Accounts can be transferred, which is awkward but possible. Artefacts have to be produced, and if nobody produced them during the build then nobody can hand them over afterwards without doing the work. That is why a handover negotiated at the end so often turns into a quote: the thing being asked for does not exist yet.
- The domain, registered to your company, in a registrar account you control and can log into today.
- The hosting or platform account, billed to you, where you can add or remove collaborators including the developer.
- The source code repository, owned by your organisation, with the full history rather than a single snapshot.
- The build and deployment process, documented well enough that a competent developer could run it.
- Any third-party service the site depends on, in accounts in your name: analytics, forms, email delivery, maps.
Why the domain is the one to settle first
Of the four, the domain is the most important and the easiest to get wrong, because it is usually bought in the first week by whoever is moving fastest.
A domain registered in an agency's account is the single point of control over your email, your website and anything else that uses it. Transferring it later is possible and requires cooperation, which is exactly what is missing in the situations where it matters. It is also the item most often forgotten, because it renews quietly in the background and nobody looks at it until a renewal is missed.
Register it yourself before any build begins. Keep the registrar login with your other company credentials rather than with the project. Give the developer access if they need it, as a collaborator you can remove, which is a different thing from them being the owner.
Email is the part that makes this urgent rather than merely untidy. The same domain usually carries your mail, so losing control of it is not only a website problem: it is an inability to receive invoices, reset passwords on other services, or prove who you are to anyone. A website can be rebuilt in weeks. A domain you cannot administer is a business continuity problem, and it should be treated as one rather than as a technical detail.
A repository is not a folder of files
Being handed a zip of files feels like being handed the code, and for a simple site it is better than nothing. It is not the same as a repository.
A repository carries the history: what changed, when, and why. That history is what makes a site safe to modify, because a change that breaks something can be identified and reversed rather than guessed at. It also carries the configuration that turns source into a working site, which a folder of output files does not contain at all.
The distinction matters most for anything beyond a brochure site. A site assembled from source files, with a build step, is only maintainable if you have what goes into the build rather than what comes out of it. Receiving the output is like receiving a printed report instead of the spreadsheet.
There is a related question about content. On a site built around a content management system, the pages live in a database rather than in the repository, so holding the code is only half of it. Ask how content is exported and in what format. A database dump you cannot read without the original system is better than nothing and worse than a documented export.
Access to the repository should also be organisational rather than personal. A repository owned by an individual developer's account, even with your team added, disappears with that account. Owned by your organisation, with people added and removed as they come and go, it survives staff changes on both sides, which is the whole point.
The test that settles it
There is one question that cuts through every reassuring answer, and it is worth asking in writing before you sign anything. Could a different developer, who has never spoken to you or to the current one, take what we hold and get the site running on new hosting?
If the honest answer is yes, you own the site. If it requires a conversation with the original developer, you do not, whatever the contract says about intellectual property. Ownership in practice is operational rather than legal: it is whether you can act without permission.
The same test applies to anything custom built for the business, which is why it appears on our custom CRM page too. Data and systems you cannot get out of are a dependency regardless of what the agreement says you own.
Running the test occasionally is worth more than running it once. Sites accumulate undocumented dependencies: a service somebody added, a manual deployment step, a credential that lives only on one laptop. An annual check that the site can still be rebuilt from what you hold catches that drift while it is cheap to fix, in the same way a restore test catches backup drift.
What a real handover document contains
A handover is a document, not a conversation at the end of a project. It should be written during the build rather than after it, because that is when the information is in somebody's head.
It names where the domain is registered and who holds the account. It names the hosting, the repository and the deployment method. It lists every third-party service the site depends on, with the account each one sits in. It explains how to run the site locally and how to deploy a change. And it records anything non-obvious: a DNS record that must not be touched, a cron job, a manual step.
We treat that as part of the work rather than an optional extra on our custom website development service, and the same expectation applies to the larger applications covered on the custom web application development page.
Two things are worth adding to the document that are not about ownership but are about continuity. The first is the accessibility standard the site was built against, because the W3C publishes WCAG and a later developer needs to know what was being maintained. The second is how the site performs and against what, since Google publishes the Core Web Vitals thresholds and a rebuild that quietly regresses on them is a change nobody intended.
What to ask before you commission anything
Everything is negotiable at the start and almost nothing is afterwards. Before the work is agreed, these questions are reasonable and easy to answer. Afterwards they are awkward and depend on goodwill.
Ask who will register the domain and in whose account. Ask whether the repository will be owned by your organisation from the first commit. Ask what the handover includes, in writing, and whether there is a charge for it. Ask what happens if the relationship ends mid-project. And ask the test question above, phrased exactly as it is written there.
A developer who answers all five plainly is telling you something about how they work. One who treats the questions as a sign of mistrust is telling you something too. If you want to talk through an existing site and what you actually hold, get in touch.
One last point about search, because it is where handover failures become visible to customers. A site moved badly loses its positions, usually because redirects were not mapped from the old URLs to the new ones. Google's own documentation on site moves and basics is the reference, and the practical requirement is a list of every existing URL before anything changes. That list is part of the handover too, and it is far easier to produce while the old site is still running.
Whether you need a custom build at all is a separate question, and usually the answer is no: why a template is usually the right answer sets out how to tell.
Frequently asked questions
Not automatically, and the contract matters less than the access. You may own the intellectual property and still be unable to move the site, because the domain sits in somebody else's registrar account and there is no repository. Ownership in practice is whether you can rebuild and deploy without permission, which is a different question from who holds the rights.
Partly. The domain still matters and should be in your account. The code question is different, because a hosted builder does not give you portable source by design, which is a trade-off rather than a failing. What you should know is that moving away means rebuilding rather than transferring, and that is worth knowing before rather than later.
The domain, without much competition. It controls your website and usually your email, it is bought early by whoever is moving fastest, and transferring it later requires the cooperation of whoever holds it. Register it in your own company account before any build starts and add the developer as a collaborator you can remove.
Have someone who has not worked on the project clone it and run the site. That is the only reliable check, and it is a short exercise. A repository can be missing configuration, environment settings or an asset pipeline and still look complete in a listing, so the test has to be running it rather than reading it.
Preparing documentation takes time, so a modest charge is not unreasonable if it was stated at the outset. What is not reasonable is discovering the charge at the end, or a charge that is really a fee for releasing access you should already have held. That is why these questions belong in the first conversation.
Start with three checks that cost nothing: look up who the domain is registered to, find out who receives the hosting invoice, and ask whether a repository exists and who owns it. Those three answers usually tell you the position, and they tell you what to fix first, which is almost always the domain.
Written by Srinivasan Ramachandran, Founder, Listonics · Published Oct 11, 2026 · Last reviewed October 11, 2026 · 2,051 words
