A project is not complete when the software works. It is complete when someone other than the people who built it can run, change and recover it. That standard is uncomfortable, and it is the right one.
Here is what a defensible handover contains.
1. A running environment somebody else created
Not a description of how to create one — an actual, observed instance built by someone who did not write the code, following the written steps. Every gap in the documentation surfaces in that one exercise, and there are always gaps.
2. A restore, performed
Backups are not the deliverable. A restore is. Take the most recent backup, restore it into a clean environment, and record how long it took and what broke. A backup that has never been restored is a hypothesis.
3. The data model, explained in prose
Schema dumps are necessary and insufficient. What a future developer needs is two pages describing the entities, their lifecycles, and the two or three non-obvious decisions — why this is denormalised, why that status field has five values, which table is append-only and must never be updated.
4. Runbooks for the four incidents that will happen
Not an exhaustive operations manual. Specifically:
- The service is down. How do you tell why?
- The database is full or slow. What do you check first?
- A deploy went wrong. How do you roll back?
- Someone needs to be locked out immediately. What are the steps?
Each one a page, each one tested once.
5. Credentials in a place the client controls
Not in your password manager. Not in a spreadsheet emailed at handover. In an account the client owns, with your access removable by them. If revoking your access breaks production, the handover is not real.
6. The decision log
The most valuable and least common artefact: a short record of the choices that shaped the system and the constraints behind them. "We chose MySQL over Postgres because the client's hosting provider supports it." "We do not use a queue because peak load is 30 requests a minute." Without this, the next developer re-litigates settled decisions or, worse, reverses them without knowing why.
7. An honest list of what is unfinished
Every project ships with known compromises. Writing them down — the missing test coverage, the endpoint that does not paginate, the manual step in month-end — is not an admission of failure. It is the difference between a maintainable system and a minefield.
Why this matters commercially
There is a school of thought that says a client who can operate the system independently will not renew. In practice the opposite happens: clients who feel trapped resent the relationship and eventually replace it wholesale. Clients who feel in control come back with the next project.
Build the handover you would want to inherit.