What a handover should contain
The test is not whether the code was delivered. It is whether a different team could take it over on a Monday morning without calling you.
Most software is handed over twice. Once formally, when the invoice is settled and someone sends a link to a repository. And once properly, months later, when a new developer needs to change something and discovers what was actually missing the first time.
The second handover is the real one, and it is the one worth designing for.
The wrong test
The usual test is completeness: was every deliverable in the contract produced? That question is easy to pass and tells you very little. Code can be delivered in full and still be unusable by anyone who did not write it.
A better test is a hypothetical. Suppose the people who built this were unavailable — not hostile, just gone. Could a competent team you hire next year open it on a Monday and ship a small change by Friday? Everything a handover should contain follows from making that answer yes.
What that requires
The system, running. Not a repository, but a documented path from a clean machine to a working local copy. If the setup lives in someone’s memory, the setup does not exist. This is the single most common gap, and the easiest to test: hand the instructions to someone who has never seen the project and watch where they stop.
The path to production. How a change gets from a developer’s machine to your customers, and how it gets pulled back when it goes wrong. A release that only one person can perform is an availability risk wearing a process costume.
The data and its history. The current shape of the data, and the ordered set of changes that produced it. A database you can only recreate by hand is a database you cannot safely restore.
The decisions, and their alternatives. This is what almost nobody hands over. Every consequential choice should exist as a short written record: what the problem was, what else was considered, why this was chosen, and what would make it worth revisiting. Without it, the next team cannot tell a deliberate constraint from an accident, so they treat everything as an accident and rewrite it.
A runbook. What breaks, how you notice, and what to do at two in the morning. Written for someone who is tired and does not have context.
The keys. Every account, domain, certificate and service registered to you, not to us. If any credential is personal to a contractor, the handover is incomplete no matter what else was delivered.
Why we care about this publicly
Because the fear is reasonable. Commissioning software from an outside team means accepting that, for a while, someone else understands your business better than you do. The honest response is not a promise about intentions — it is to make leaving cheap, and to say so before the work starts rather than after.
Anything else is a way of keeping a client by making the exit expensive. That is a business model, but it is not engineering.