Handover is a document, not a meeting.
That distinction is the whole point of this list. Almost every bad handover we inherit went the same way: there was a call, it was friendly, someone shared a folder, everybody agreed it had gone well, and the final invoice was paid. Six months later a new developer opens the repository and cannot get it running, and the person who could explain it has moved on and owes you nothing.
The final invoice is the only leverage you will ever have. It is not adversarial to use it — a competent supplier expects to be asked for all of this, and most of it should already exist. Work through the list before you pay, not after.
Access — the things that are painful to recover
1. The repository, in an organisation you own. Not a personal account that has granted you access. If the code currently lives in someone’s individual account, transferring it is a two-minute job for them and a legal conversation for you. Do it now.
2. Full commit history. Not a fresh repository with one “initial commit” containing the final state. The history is the only honest record of how the thing was built, and it is the first thing a good auditor reads.
3. Cloud accounts in your company’s name, with billing under your control. Technical access is not enough. Whoever pays the bill owns the environment.
4. Domain and DNS, in your registrar account. Check who the renewal notices go to.
5. App store accounts under your company. If your app is published under a supplier’s Apple or Google account, you cannot ship an update without them. Moving a live listing between accounts is measured in weeks and can interrupt availability.
6. Every third-party service. Payment provider, transactional email, error tracking, analytics, SMS, maps, push notifications, feature flags. Ask for a written inventory — service, what it does, whose account, what it costs. This is the item most often incomplete.
7. Secrets, delivered properly. An .env.example listing every variable the application needs, plus the real values shared through a password manager. Not pasted in a chat message, and not “we’ll send those over”.
Runnability — can a stranger start on Monday?
8. A README that works on a clean machine. The test is literal: a developer who has never seen the project follows it on a fresh laptop and gets the application running locally. If your supplier cannot demonstrate that, it is not done. This single item prevents more grief than the rest of the list combined.
9. Working migrations from an empty database. Not a database dump someone restores by hand. Migrations that run cleanly from nothing, in order.
10. Seed or sample data. Enough to log in and see a populated interface. Without it, a new developer’s first day is spent inventing test data instead of reading code.
11. A documented deploy. How does code reach production, who can trigger it, and how do you roll back? “Dave pushes from his laptop” is an answer, and it tells you what you have bought.
Understanding — the parts nobody writes down
12. An architecture note, two pages maximum. What the pieces are, how they talk to each other, and — most valuable of all — why the awkward decisions were made. Every codebase has three or four choices that look wrong until someone explains the constraint. Get those written down while the person who made them still cares.
13. The known-issues list, honestly. Every project has one. A supplier who says there are no known issues is telling you they have not written them down, not that none exist. Ask specifically for the things they would fix given another month.
14. Test suite and how to run it. Including which parts are not covered. Knowing that payments have no tests is far more useful than a coverage percentage.
15. A recorded walkthrough. Thirty to sixty minutes of someone screen-sharing the codebase and the admin surfaces, talking as they go. It is the cheapest item here and routinely the most useful six months later, because it captures the things nobody thinks to write down.
The three people discover too late
Of everything above, three are almost always the ones missing when we are called in to take a project over.
The clean-machine setup. Everyone assumes it works because it works on the machine it was built on. Nobody tests it from scratch until the person who built it has gone.
The architecture reasoning. Not the diagram — the why. Without it, the next team spends its first month either re-deriving the constraints or, worse, “fixing” a deliberate decision and breaking something subtle.
The third-party inventory. It surfaces as a series of small emergencies over the following year: an expired key, a service nobody knew was being paid for, a rate limit hit at the worst possible moment.
How to actually run it
Send the list before the final milestone, not on the last day. Frame it as the definition of done, because that is what it is. Then treat the invoice as contingent on the items, and verify the two that cannot be faked: have someone else run the setup on a clean machine, and watch the deploy happen.
If a supplier objects to any of this, that is information. Everything on the list is either something a well-run project already has, or something that takes a day to produce. The objection is rarely about the effort.
Already past this point, holding code nobody can read? That is the ordinary starting position for a project rescue — and the honest first step is The Memo, a written keep, fix, or cut on what you actually hold. If you would rather get a rough read yourself first, the technical debt assessment takes about two minutes.