Why we hand over the source code

Ask an agency who owns the code at the end of a project and you will get one of three answers. "You do, on final payment" is the good one. "We license it to you" means you are renting the thing you paid to have built. And a long pause followed by "well, it depends what you mean by own" means the question has never been asked by a client who then walked away.

Our answer is the first one, in writing, before anything starts. That is not generosity and it is not a differentiator we invented for a sales page — it falls out of a view about what the work is for. If a system cannot outlive its relationship with the people who built it, it is not an asset on your balance sheet. It is a dependency.

The commercial logic of not handing it over

It is worth being fair to the other side, because the incentive is real and it is not always cynical.

An agency that retains the code has a client who cannot leave. Every change request comes back to them at their rate. Revenue is predictable, the relationship compounds, and the team never has to win the same client twice. From the inside this rarely feels like a trap being set — it feels like continuity, and continuity genuinely does produce better software than a new team relearning the domain every eighteen months.

The problem is what it does to the incentive at the margin. When the client cannot leave, nothing punishes a system that is slightly harder to understand than it needs to be. Nobody sets out to write code that only one team can maintain. It is simply what happens when no force is pushing the other way.

What a handover has to contain to be real

Here is the part that matters more than the ownership clause: a repository transfer is not a handover. You can own every line of code and still be unable to change any of it. We have inherited systems where the client legally owned everything and could not deploy a copy change without calling the original team, because the deploy pipeline lived in someone’s personal account.

A handover that means something contains all of this:

• The repository, with its full history — not a squashed initial commit. The history is where the reasoning is.
• Infrastructure defined as code, in your accounts, under your billing. If any part of production exists only as settings someone clicked in a dashboard, it is not transferred.
• Every credential, rotated at handover and held by you. A shared secret that we still know is a dependency with a friendly face.
• A runbook that covers deploying, rolling back, restoring from backup, and the three things most likely to page someone at 3am.
• Architecture notes explaining why, not what. What the code does is readable from the code; why it does it that way is the expensive part to reconstruct.
• A working local environment that a new engineer can start from a clean machine, following written steps, without asking us anything.

The last one is the honest test, and it is the one we use internally. If a competent engineer who has never seen the project cannot get it running and ship a small change by following the documentation, the handover is incomplete regardless of what the contract says.

What we keep

We are not claiming to hand over everything, because that would not be true and a policy stated too broadly is a policy nobody can rely on.

We keep general know-how — the patterns, the judgement, the accumulated sense of which approaches fail slowly. We also keep any pre-existing components we brought with us, licensed to you perpetually for use in what we built. That is what allows the next project to start from more than zero, and it is also why we can quote a number that assumes we have solved multi-tenancy before.

What we do not keep is anything you need in order to run, change, or leave.

The uncomfortable consequence

Building this way is more expensive for us, and the cost lands in places that are easy to skip. Documentation written while the reasoning is still fresh. Infrastructure done properly in your account rather than quickly in ours. Refusing the shortcut that would work fine as long as we are the ones maintaining it.

It also means clients continue working with us by choice. Most of our engagements do continue beyond the first project, and we believe that is the right basis for a long-term relationship.

The question to ask any agency is not "do we own the code". It is "if we ended this tomorrow, what would we not be able to do without you?" The honest answer to the second question tells you what the first one is worth.