Who owns the code? A handover checklist
What you should own when a website, app or automation is finished, what the handover should include, and which wording in a quote deserves a second question.
By Daniel Aideborn · Published 29 September 2026 · 3 min read
Short answer: you should own the code, the data, the accounts and the documentation, and be able to change supplier without asking anybody's permission. If any of the four stays with whoever built it, what you own is in practice a rented solution.
Below is what each of the four means, what a handover should contain, which wording in a quote is worth a second question, and five questions to ask before you sign.
Four things you should own
| What | Why | How you know it is yours |
|---|---|---|
| The code | Without it nobody else can change or extend anything | It lives in a repository where you are the owner, not a guest |
| The data | Customers, orders and content are the business | You can export all of it, whenever you like, at no extra cost |
| The accounts | Domain, hosting and services decide whether the site lives | They are in your name and on your invoice |
| The documentation | The next person should not have to guess | It says how everything runs, deploys and is fixed |
What matters is the difference between access and ownership. A supplier may need access to do the work. But if you cannot remove that access yourself, you are not the one who owns it.
What the handover should include
- The repository with all the code, transferred to your account or organisation, with its history intact.
- A description of how the solution runs, builds and deploys, so that someone else can do it without asking.
- A list of every service the solution uses, what each costs and who pays for it.
- Logins and keys handed over, and the ones the supplier used changed or removed.
- A short guide to what you should be able to do yourself: change text, add a user, pull a report.
- Known shortcomings, and what was deliberately left for later, written down.
Wording worth a second question
- "The code belongs to the supplier" or "you receive a licence to use". Then you are renting, even though you paid for the build.
- Hosting only through the supplier. Convenient at first, but moving becomes a negotiation rather than a transfer.
- Data export for an extra fee. Your data should come out without costing more.
- No mention of documentation. What is not in the quote is rarely delivered.
- The supplier's own platform. It can work well, but ask what happens to the site if the platform closes or changes its price.
Put it in the contract that the code and the rights to it become yours once the build is paid for. Without such a clause it is not a given that they do.
What I do
You own it. Everything is delivered into your repository with documentation, and it runs on your accounts and infrastructure. I work under an NDA by default when data is involved. The last step of every engagement is exactly this handover: I build it, you try it, and it runs on your own accounts when we are done.
Which accounts that means, and why they belong in your name, is covered in Domain, hosting and business email.
Five questions before you sign
- Whose account does the code live in during the build, and when does it move to you?
- Can I export all the data myself, and in which format?
- Which accounts and services are needed, and are they in my name from the start?
- What does the documentation include, and who writes it?
- What happens to the solution if we stop working together?
The answers say more about an offer than the price does. If you want me to look at your case, the services are on the home page and the contact box is at the bottom of it.
Related services: Web apps