The build is finished. The agency has delivered, been paid, and moved on to its next client. You have your software — and now you are on your own with it. This moment, the handover, is the most under-managed point in any software project, and it is where businesses quietly inherit problems that surface months later. What you need at this moment is mostly determined before it arrives, which is why it is worth thinking about handover long before the agency walks away.
Why handover is where things go wrong
During the build, the agency holds everything — the code, the knowledge, the context, the ability to fix and change things. When they leave, all of that has to transfer to you, or you are dependent on them forever, or stranded. Most handovers are treated as an afterthought: the work is delivered, the invoice is settled, and the deeper transfer never properly happens. The business discovers the gap the first time something needs changing or fixing and the people who understood it are gone, charging premium rates to return, or unavailable entirely.
What you actually need to receive
A proper handover transfers more than a working system. You need the code itself, in your possession and under your control — not sitting only on the agency’s accounts, where you do not truly own what you paid for. You need access to everything the system runs on — the hosting, the services, the domains — in your name. You need documentation: how it is built, how it works, how to run and maintain it, so the knowledge does not live only in the departed agency’s heads. You need to know its dependencies — what it relies on, what could break, what needs attention over time. And you need clarity on support: what happens when something goes wrong, who fixes it, and on what terms.
Free · 4 minutes
Is your engineering team shipping safely, or quietly accumulating risk?
Fourteen questions on how work gets from idea to production — cadence, testing, rollback, and the key-person risk in your delivery. Banded finding on screen, full sheet by email.
If you cannot get these, you do not really own your software — you are renting dependence on the agency, whatever the contract says.
Why it must be set up at the start
The decisive point: a good handover is created at the beginning of the project, not negotiated at the end. Ownership of the code, access in your name, documentation as the work proceeds, and clear support terms are all things to establish in the specification before any building starts — which is part of what a proper software specification should cover and part of how you manage an agency throughout. Try to arrange them after the build, when the agency has been paid and has no incentive to cooperate, and you have lost your leverage. The handover you get is the handover you set up months earlier.
What comes next
Software is not finished when the build ends; it needs running, maintaining and evolving for as long as the business uses it. So “what comes next” is a real question: who looks after this now, how does it get changed safely, and how do you avoid being permanently dependent on the agency or stranded without them? Independent oversight, the model in build and oversee, is what ensures the handover is real and that you have a plan for the system’s life after delivery — not just its birth.
The end of a build is where ownership is won or lost. If an agency is finishing, or you are about to commission one, I can make sure you actually receive what you paid for. We will get the handover right.
Start a ConversationFree interactive tool
Website compliance checklist
What your site has to do, based on what it actually does
Answer as much or as little as you like — the list builds as you go. Nothing is stored against your name and no email is required.
Everything that applies
Ordered by what to do first: legal requirements you can close quickly, then larger pieces of work, then what is expected rather than required. Not exhaustive, and not a legal audit.
Dated PDF, yours to keep or circulate.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.