What we hand over at the end of a project

Handover is the part of a project most likely to be described in a proposal and least likely to be defined. 'Full documentation and handover' appears in nearly every statement of work; almost none of them say what that means, which is convenient for the party writing it.

So here is ours, in full. You are welcome to hold us to it, and you are welcome to take this list to whoever you hire instead and ask what theirs looks like.

1. The architecture summary

Two to four pages, written for a competent engineer who has never seen the project. Not a diagram export — prose, because the useful information is the reasoning, and diagrams do not carry reasoning.

• What the system does, in one paragraph, in business terms.
• The main components and how data moves between them.
• The decisions we made and what we rejected — this is the section people actually re-read, because it answers 'why on earth is it done this way' eighteen months later.
• Known limitations and the conditions under which each would need revisiting.
• The parts we would build differently with more time or budget, named honestly.

2. The runbook

Everything that needs doing to keep the thing alive, written as instructions rather than as description. If a step cannot be followed by someone who did not build the system, it is not finished.

• How to deploy, and how to roll back.
• Environment variables and what each one does.
• Scheduled jobs — what runs, when, and what it means if one does not.
• The three or four failures most likely to happen, with the first diagnostic step for each.
• Who to contact, and for what.

3. The access inventory

The least glamorous document and the one clients thank us for most. Every account and service the project touches, who owns it, what it costs, and what breaks if it lapses.

This exists because the most common way a small company loses control of its own systems is not dramatic. It is a domain registered on a personal card, an API key nobody can rotate, and an analytics property owned by an agency that stopped replying. An inventory makes that failure mode visible while it is still cheap to fix.

Your repository, your hosting, your accounts — from day one, not on final payment.

4. The walkthrough

A recorded session going through the codebase and the runbook out loud. Thirty to sixty minutes. The recording matters more than the meeting, because the person who most needs it is usually someone you have not hired yet.

Why we publish this

Partly because it is a real differentiator and we are not pretending otherwise. But mostly because writing it down changes our own behavior: a documented handover standard is much harder to quietly skip at the end of a project that ran long, which is precisely when handover is most likely to be skipped and most valuable.

The test we apply is simple. If we disappeared the week after launch, could a competent engineer pick this up from what we left behind? If the answer is no, the project is not finished, regardless of whether the software works.