Six months after the engagement ended, the message arrived. "Hey! Quick question. The thing that syncs the inventory, where does that live again?" The honest answer was "in my head," which is precisely what the final month of the engagement had been supposed to fix.
There are two kinds of goodbye in this business. One leaves a binder nobody opens and a Slack thread that never quite dies. The other leaves a system that keeps working and a client who calls you back because they want to, not because they're stuck. A real software project handoff checklist is the difference, and it has five parts: documentation of decisions rather than descriptions, access transferred into the client's accounts, runbooks for the top failure modes, monitoring owned by a named human, and a tapered exit. Run every item against the bus test before you leave, because the deliverable of the final month is your own dispensability.
The bus test, defined
The bus test is a thought experiment with a cheerful rebrand: if the FDE wins the lottery and moves to a beach tomorrow, does the system survive the week? Not thrive. Survive. Orders flow, errors get noticed by someone whose job it is to notice, and everybody knows who to call.
Every checklist item exists to pass that test. The handoff that went right is worth reading as the positive control: nothing in it is heroic, which is exactly why it worked.
The negative control is more common. A composite distributor lost its FDE to a parental leave, which is the polite version of the bus. The system ran fine for nine days. On day ten a credentials token expired, and nobody knew where the token came from, which service issued it, or which of the fourteen environment variables was the one to rotate. Three days of downtime, one emergency invoice, and a lesson purchased at full price: the system hadn't failed, the handoff had, nine days delayed.
Cruelly, everyone involved knew a handoff had happened. There was a document. There was a meeting. The meeting ran long, people got hungry, and the credential-rotation discussion got bumped to "next week." Next week was nine months ago.
The software project handoff checklist
Five parts, in the order clients usually get them wrong:
- Decision docs, not description docs. Half a page per significant choice: why Postgres and not Airtable, why the sync runs at 2 a.m., what would make you revisit it. The code already says what it does; only you can say why.
- Access and credentials, transferred. Every account lives in the client's password manager, billing emails point at them, and deploy keys don't live in your personal GitHub. You should end the engagement as a guest with revocable access, not as the landlord.
- Runbooks for the top five failure modes. Symptom, cause, fix, escalation. "If the 2 a.m. sync fails: check the credentials page, restart the worker, and if it's still red after fifteen minutes, call this number."
- Monitoring with a named owner. An alert nobody owns is a tree falling in an empty forest. One named human per alert, plus a weekly ten-minute review.
- A recorded knowledge-transfer session. Ninety minutes, recorded, and the person who couldn't attend watches the recording before you leave, not after something breaks.
A special note on the second item, because it's the one that bites hardest: the domain registrar. More engagements end with the client's domain registered in the consultant's personal account than anyone admits. Transfer it, along with the DNS, the payment method, and the renewal email, while everyone is still friendly and answering messages.
Document decisions, not descriptions
The most-skipped item deserves its own section. Description docs rot instantly; the code drifts and the doc becomes a lie with a date on it. Decision docs age like wine, because the reasoning stays true even after the implementation changes. Today's shortcut is tomorrow's archaeology dig, as the prototype tech debt field guide argues, and the kindest thing you can leave the next engineer is a note explaining why the shortcut made sense at the time.
A usable template has four lines: context, options considered, why this one won, and what would change the answer. If you can't fill in the fourth line, you haven't finished the decision, let alone the doc.
Here's a real example. "Context: the 3PL-API has a 100-request-per-minute limit. Options: batch overnight, pay for higher tier, or cache inventory and accept five-minute staleness. Winner: cache with staleness, because oversells at our volume cost less than the API tier. Revisit if: monthly order volume crosses 50K." That's it. Thirty seconds to read, ten minutes to write, and infinitely more useful than a paragraph describing what the cache code does.
The gradual exit
Big-bang handoffs fail because they assume knowledge transfers in a meeting. It transfers in weeks of decreasing involvement. The shape that works: full-time, then two days a week, then weekly office hours, then a thirty-day tail clause for genuine emergencies.
The metric for the whole taper is client questions per week, and it should trend to zero. If it isn't trending, something is still in your head, and your job is to find it and write it down. Price the tail clause honestly too: a small fixed fee for thirty days of emergency availability, with a definition of emergency written down, so neither side spends the month wondering what a "quick question" costs. A release rhythm the client can keep without you is part of this; the weekly release cadence is designed to be exactly that kind of inherit-able habit. And the docs themselves should be built the way the rapid prototyping playbook builds software: small, shipped, and improved in the open, not unveiled as a ninety-page PDF on the last Friday.
Red flags in your own handoff
Some warning signs are about the client. They can't name the top failure mode. Nobody there has deployed in a month. The "quick questions" keep arriving monthly, each one small, each one proof of a gap in the docs.
The mirror image is worth watching for too, because it's the green flag: the client starts answering their own questions. Someone finds the runbook before messaging you. A new hire gets onboarded from the decision docs without a meeting. When the system starts teaching people, the handoff has already happened, and the rest is paperwork.
One red flag is about you: the quiet pleasure of being needed. It feels like job security. It behaves like a hostage situation, for both sides, and the only way out is the checklist above, executed while you still like each other.
The best handoff is boring. Six months later there's no message, because the inventory sync lives in a runbook, the alerts go to someone named Dana, and the only reason the client calls is the next project. That's the goodbye worth engineering.