Design the handover before the first commit
The exit is the part of an engagement most likely to be skipped, so we make it a contractual line item.
Handover fails for a structural reason, not a moral one. It happens at the exact moment the budget is exhausted, the client is impatient to launch, and the agency's attention has already moved to the next project. Everyone intends to do it properly and nobody has any remaining incentive to.
So we move it. Handover is scoped, priced, and scheduled at the start, and it is a milestone with an invoice attached like any other.
What is actually in it
- A README that a new engineer can follow from clone to running locally, tested by watching someone do it
- An architecture note listing decisions and, importantly, the options we rejected and why
- A recorded walkthrough, because the person who inherits this may not have been hired yet
- A runbook: what alerts exist, what they mean, and who to call
- A review period where the client's engineers open the pull requests and we comment
That last item is the one that reveals whether the rest worked. If your engineers can ship a real change with us only commenting, the handover happened. If they cannot, we find out while we are still being paid to fix it.
The commercial cost
This shortens engagements. A client who can maintain their own system does not need us next quarter, and we have watched revenue walk out of the door on good terms more than once.
It also means every one of those clients answers the phone when we ask for a reference, and several have come back with larger projects. We have not run the numbers rigorously enough to claim it is optimal. We are fairly confident it is not a mistake.