The test of a build is not whether it launched. It is whether the client's team shipped anything to it in the ninety days after we left.
By that measure, most agency work fails, and it fails for a reason you can design around.
Why handover fails
A handover is usually an event: a two hour call, a folder of files, a recorded walkthrough nobody watches twice. It transfers artefacts and not the ability to change them.
Three months later the team needs to add a field. They can find the component. They cannot find the reason it works the way it does, so they either copy it badly or call us.
Documentation explains what exists. Handover has to explain what would make you change it.
What we leave
Four things, produced during the build rather than assembled at the end.
- The decision log. Every significant choice, when it was made, and what would justify reversing it. It is written weekly, not retrospectively, because the reasoning is unrecoverable a month later.
- The cut list. What we deliberately did not build, ordered. This becomes the roadmap, and it is the single artefact clients quote back to us most often.
- One change, made by them. Before the engagement ends, someone on the client team ships a real change to production with us watching but not typing. It is the only reliable test of whether the handover worked.
- The escalation path. What to do when something breaks at 2am, written by someone who has been woken up by it.
The part that costs
Item three is the expensive one. It means finishing a week early in effect, because the last week is spent watching someone else work slowly instead of working quickly ourselves.
It is also the only item that reliably predicts whether the team is still shipping in month four. We have stopped treating it as optional, and we price it in rather than discovering it in the final fortnight.
