Insight
Software handover checklist: what you should own
Source code is the easy part, and the part everyone remembers to ask for. The real list is longer, and its gaps only show when you need them.
The moment to work out what you own is before the project starts, not on the day someone sends you a zip file and stops replying to email.
Most handover conversations happen at the worst possible time: at the end, when the budget is spent, the team is moving on, and whatever you forgot to ask for is now a favour rather than an obligation.
The list
Each item below is also in our free software handover checklist, ready to drop into a contract.
The source code, and its history. Not a final snapshot: the repository, with commits. History tells the next developer what changed and when, which is most of how they learn a system without you paying for the lesson twice.
Setup instructions that someone else has followed. “It runs locally” is a claim, not a deliverable. The test is whether a developer who has never seen the project can go from a clean machine to a running copy using only the written steps. If nobody has tried, assume it doesn’t work.
The accounts, in your name. This is the one that bites hardest. Hosting, domain, database, payment processor, error tracking, the app store listings. If any of those were created under your builder’s account, you don’t own your product. You rent it from someone who has moved on.
Documentation of how it runs. Not a description of the features. You know the features. What runs where, what talks to what, what happens when it breaks, and who to call. One page that answers those is worth fifty pages that don’t.
Tests on the journeys that matter. Not total coverage. The handful of paths where a silent failure costs you money or a customer: signing up, paying, the core thing the product does.
The decision record. The short version of why the shape is the shape. Why this database, why that integration, what was tried and abandoned. Without it the next team’s first instinct will be to rewrite, because everything undocumented looks arbitrary.
A system you can run is worth more than a system you own. Ownership without the ability to operate it is a filing cabinet.
What “done” should mean
Done isn’t “the last feature works.” A useful definition has three parts: the software runs in production, someone other than the original developer has deployed it successfully at least once, and there is a written agreement covering what happens next.
That last part is where projects quietly become dependencies. Either you have a support arrangement with an agreed scope and response expectation, or you have a clean exit with everything above in your hands. What you don’t want is the third state: no agreement, no handover, and a phone number you hope still works.
How to get it without a fight
Put the handover in the scope, at the start
Ask for the list above in writing before the work begins. A builder who has planned for it will say yes immediately. One who hesitates has told you something useful.
Test it in the middle, not at the end
Halfway through, ask someone on your side to follow the setup instructions on a clean machine. Whatever is missing is cheap to fix now.
Do a real handover session
An hour with someone from your side, walking through deploying, monitoring and the three things most likely to break. Record it.
If you want this as a tick-box list, download the handover checklist. None of this is adversarial. It’s the same list a competent builder wants to hand over anyway, because a client who can run their own system is a client who calls about new work rather than about access.
Every project we take on includes this by default: the code, the setup, the documentation, tests on the core journeys, and an agreed support arrangement or a clean exit. Not because it’s generous, but because it’s what a finished project is.