The handover is part of the product.

Most software is judged on the day it launches. We think it should also be judged on the day someone else has to change it.

That day always comes. A client hires an in-house developer, a new feature needs a different team, or the client simply wants the option to leave. If the system only makes sense to the people who built it, the client doesn't own a product. They own a dependency.

"You own the code" is easy to write in a proposal. This article is about what it means technically: what to check, where ownership usually leaks, and what leaving really costs.

If the system only makes sense to the people who built it, the client doesn't own a product. They own a dependency.

Ownership is a list you can check

Ownership is not a feeling or a clause. It is a set of things that are either in your name and within your reach, or not. They fall into five groups: the code, the documentation, the infrastructure, the licences, and the cost of leaving. Each can be checked in an afternoon.

The code

Where it lives. The repository should sit in your organisation on GitHub, GitLab or similar, with you as an owner and any vendor as a collaborator you can remove. A zip file of the final version is not the code: the history of why each change was made is part of what you paid for.

How it is structured. A repository is only yours in practice if someone new can find their way around it. That depends on a few unglamorous choices:

• Conventions over cleverness. We build in TypeScript and keep each framework's standard layout: routes, logic and configuration where a developer who knows the framework expects them. Someone new needs no tour.
• Migrations as files. Every schema change is a numbered migration in the repository, so the database's history reads in order and any environment can be rebuilt from scratch.
• Decisions written down. A short log of what was chosen, what was rejected and why. "One database instead of two, because reporting needs joins across bookings and customers" stops a future developer from undoing something for a reason they never saw.
• No secrets in the repository. Credentials live in the hosting platform or a secrets store; the repository holds an example file that names each one.
• Runnable from scratch. Local setup is a short list of commands, tested on a clean machine. If a step only exists in someone's memory, it isn't documented yet.

Documentation a stranger can ship from

We hold documentation to one test: a competent developer who has never seen the project should be able to ship a small, real change within their first week, without needing a call with the people who built it.

In our projects that documentation starts from one file at the root of the repository, HANDOVER.md, with the same outline every time:

HANDOVER.md

1. What this is        one paragraph: users, core journey
2. Run it locally      exact commands, from clone to running
3. Deploy              how a change reaches production
4. Where things live   services, accounts, who has access
5. Data                main tables, backups, how to restore
6. Never breaks        the guarantees, and the tests that hold them
7. Known limits        what we chose not to build, and why
8. First tasks         three small changes to learn the codebase

Two sections do most of the work. Never breaks lists the guarantees, linked to the tests that protect them, so a new developer learns what must not be touched casually before anything else. Known limits is the honest part: the feature deferred, the step kept manual, the report run by hand. Written down, they become a roadmap instead of surprises.

Infrastructure access

This is where ownership leaks most often, usually by accident, because someone set an account up quickly in the first week.

• Hosting, database and deployment. The accounts are registered to the client, with the developers as members. The difference matters: a member can be removed, an owner can't.
• Domain and DNS. In the client's own registrar account. A domain registered to an agency is one of the most common ways a business gets stuck.
• Third-party services. Email delivery, maps, payments, AI providers: the client's accounts and the client's billing, so nothing stops working because someone else's card expired.
• The email behind the accounts. Accounts registered to a developer's personal address are owned by that developer in every way that matters. Use a company address, and keep the two-factor recovery codes somewhere the company controls.
• Credentials. In a password manager or secrets store the client controls, never in a chat thread or a spreadsheet.
• Backups. A backup nobody has restored is a hope, not a backup. Restore the production database into a separate environment, check the application runs against it, and write down the date.

Licences

Having the files is not the same as having the right to use them. Licences are worth checking before launch, not when a new team asks.

Copyright in the custom code. Who owns code written for you is set by the contract, not by whose account the repository is in. Make sure the agreement assigns it to you, and when.

Open-source dependencies. Almost every project is built on open-source libraries. Their licences allow use, but some come with conditions. A generated list of dependencies and their licences, kept with the code, means nobody has to reconstruct it during a due-diligence check.

Paid assets. Fonts, icon sets, stock photos, themes and plugins are licensed, not owned. The licence should be in the client's name and cover how the asset is actually used: on the web, in an app, on how many domains. An asset licensed to an agency for its own projects is a common surprise.

Service terms. AI providers, maps and payment services each have usage limits and data terms. On the client's own account, those terms are the client's to read and accept.

The cost of leaving

Every system has an exit cost. The question is whether it is a few planned weeks or a rescue. You can estimate it before you ever need to leave:

• Time to a first change. How long would a new developer need to ship something small? With good documentation, days. Without it, weeks of reverse-engineering.
• Your data, without help. Can you export it in a plain, documented format yourself: a database dump, or files from an admin screen?
• Proprietary pieces. A framework only the vendor knows, hosting only the vendor can reach, a closed content system: each one multiplies the cost of leaving.
• What isn't code. Design files, brand assets, copy, translations, and access to analytics and search consoles. They don't live in the repository, so they are easy to forget, and they are often the first thing a new team needs.
• Open work. Anything half-finished should be listed with its branch and next step, not explained from memory.

Some vendors make leaving expensive on purpose. We avoid it for practical reasons as much as principled ones: a client who can leave at any time stays because the work is good, and that is the only kind of long-term relationship worth having.

An ownership checklist

Run it on any system you pay for, ours or anyone else's. Every item is something you can check yourself.

CODE
[ ] Repository in your organisation, with its full history
[ ] You are an owner; vendors are collaborators you can remove
[ ] Runs locally from the README, tested on a clean machine
[ ] No credentials stored in the repository

DOCUMENTATION
[ ] A handover document: run, deploy, data, never breaks, known limits
[ ] A decision log: what was chosen, what was rejected, and why
[ ] Every schema change as a numbered migration

INFRASTRUCTURE
[ ] Hosting, database and deployment accounts in your name
[ ] Domain and DNS in your own registrar account
[ ] Third-party services on your accounts and your billing
[ ] Accounts on a company email, with recovery codes you hold
[ ] Credentials in a password manager you control
[ ] A backup restored at least once, with the date written down

LICENCES
[ ] Copyright in the custom code assigned to you
[ ] A list of open-source dependencies and their licences
[ ] Fonts, images, themes and plugins licensed in your name

EXIT
[ ] Your data exportable in a documented format, without help
[ ] Design files, brand assets, copy and translations in your hands
[ ] Analytics and search console access in your name

Related: see how handover fits into a project →