Every consultancy says it hands over properly. In practice the handover is often a credentials document, a walkthrough call, and an invitation to email if anything comes up.
That is not a handover, it is a forwarding address. And it is expensive in a predictable way, because the cost of changing a technical decision does not stay flat.
The last column is the one worth attention. It is high not because the code is harder to change after handover, but because the reasoning is gone. A maintainer facing a strange-looking decision has two options, and without context both are bad: preserve a constraint that expired eighteen months ago, or remove one that is still load-bearing and find out in production.
What we actually hand over
A runbook. How to deploy, how to roll back, what the alerts mean, what to do at 2am when the sync job fails. Written by the person who built it, verified by someone else following it without help. A runbook nobody has tested is a document, not a procedure.
Architecture decisions, with the rejected options. Short entries: what we chose, what we did not, and why. The rejected options are the valuable half. Code records what was decided and never records what was considered, which is why “why is it like this?” is the most expensive question in software.
Your engineers already in the repository. Not access granted on the last day, but commits during the build. The point is not training; it is that someone on your side has argued with a decision while the person who made it was still there to answer.
A support window with an end date. Ours is thirty days, included, and then a retainer if you want one. An open-ended “just email us” sounds generous and is worse: it has no service level, it decays as we get busy, and it quietly discourages you from building your own capability.
The part that is uncomfortable
A proper handover makes the supplier replaceable. That is the point, and it is also why it is so often thin. A client who can maintain the system without you is a client who might not renew.
We would rather be chosen than retained by default. The practical version of that is a handover good enough that leaving is genuinely an option for you, which is also the only credible way to promise that you own what we built.
If you are buying
Ask for the handover contents in the proposal, not at the end. Two questions do most of the work: what will we be able to do without you on day one, and who has tested that. A supplier who has done this before will answer specifically. One who has not will answer with reassurance.