The handoff that survives your departure

You shipped. It works. The demo went well, the sponsor is happy, and your engagement ends in two weeks.

Six months later the system is either load-bearing or abandoned, and which one it becomes has very little to do with how good the code was.

This is the part of forward-deployed work that separates the engineers clients ask for by name from the ones who did a fine job once. It is also the part with the least written about it, because it happens after everyone has stopped paying attention.

What actually kills a delivered system

Not bugs. Four things, in rough order of frequency:

1. Nobody owns it. It was your project. On your last day it becomes nobody's project. The first time it misbehaves, there is no one whose job it is to look, so it gets routed around instead of fixed. Routing around it is permanent.

2. The model it was built on gets retired. This is not hypothetical — in the first half of 2026 alone, Sonnet 4 and Opus 4 were retired in June, Opus 4.1 in August, and two models were suspended worldwide for nineteen days by government order. If the model ID is pinned in three files and nobody knows where, the retirement notice is a crisis rather than a ticket. See when your AI model disappears.

3. A schema changes upstream. Someone renames a column in the ERP. The agent starts returning subtly wrong answers rather than erroring. Nobody notices for weeks, and when they do, trust is gone.

4. The champion leaves. The one person internally who understood the system and advocated for it takes another job. Everything that lived in their head goes with them.

Notice that three of the four are organisational and one is a deprecation. None of them are code quality. You cannot engineer your way out of any of them — but you can hand over in a way that makes each survivable.

Name the owner, in writing, before you go

The single highest-leverage thing in a handoff, and the one most often skipped because it is a conversation rather than a task.

Not "the IT team." A person, by name, who has:

• Agreed to it out loud, in a meeting, with their manager present
• Time allocated — even two hours a month is enough if it exists on paper
• The access to actually fix things — credentials, permissions, the ability to deploy

An owner without the third item is a name on a page. This is the item that quietly fails most often, because access provisioning is somebody else's queue and your engagement ends before it clears. Check it yourself. Watch them log in.

If you cannot get a named owner, escalate that to the sponsor as a risk in writing before your last week. It is the highest-probability failure in the whole handover, and it is entirely within their control.

Write the runbook as failure modes, not architecture

Most handoff documents describe how the system is built. That is the wrong document. The person reading it in month six is not curious about your architecture — something is broken and they need it to stop.

Organise it by symptom:

The agent says "I don't have data on that" for things it used to answer

Almost always the nightly sync failed. Check sync_log for the last successful run. If it is more than 36 hours old, [runbook link]. If the sync is healthy, check whether the field null-rate has moved — see the data-quality dashboard.

Answers are confident and wrong

Usually a schema change upstream. Run scripts/check-schema.ts; it compares live columns against the ones the retrieval layer expects and prints a diff.

Costs jumped this month

Check the Console analytics by user first. In two out of three cases it is one person running a batch job through an interactive path.

It stopped working entirely after a date in the news

Check whether the model was retired. Model IDs live in config/models.ts — there is one file, deliberately.

Ten symptoms, each with a first check and a link. That document gets used. A thirty-page architecture overview does not.

Make the deprecation survivable in one commit

Since you know a model retirement is coming — annually, roughly — build for it before you leave.

One file holds every model ID. Not three. Not a default buried in a client wrapper. One file, and the runbook names it.

Write the migration test before you go. A script that runs your eval set against a different model ID and prints a pass-rate diff. When the retirement notice arrives, the owner's job is: change one line, run one script, read one number. That is a task a competent person can do without understanding your architecture.

Leave the eval set behind, with its answers. This is the artifact most engineers forget and the one that matters most for longevity. Twenty real questions with agreed-correct answers, in a file, runnable. Without it, nobody can tell whether a change made things worse — so nobody changes anything, and the system slowly stops matching reality. See auditing your eval suite.

Set the ceiling honestly, in writing

Your last document should state what the system does not do and what would need to happen for it to do more.

This feels like undermining your own work. It is the opposite. Six months from now someone will ask the system a question outside its scope, get a bad answer, and conclude the whole thing is unreliable. The document that says "this covers the five question types listed; anything about pricing is out of scope and will be answered badly" converts that moment from a loss of faith into a known limitation.

Write down the things that would break it, too: a new warehouse, a change in the fiscal calendar, a fifth product line. Whoever inherits it will hit one of these, and recognising it as an anticipated event rather than a mystery is the difference between a ticket and an abandonment.

The 30-day check-in

Negotiate one before you leave — an hour, a month after your last day, on the calendar with an invite already sent.

Almost nothing surfaces in the final week, because everyone is being positive and the system has not met a real month yet. Everything surfaces at day 30: the questions nobody thought to ask, the first upstream change, the thing the owner has been quietly working around because they did not want to bother you.

An hour at day 30 saves systems. It is also, commercially, the most reliable source of follow-on work I know of — not because you sell in it, but because it is when the client discovers what else they need.

The test

Here is the honest measure of a handoff, and it is uncomfortable:

Could a competent engineer who has never met you keep this running for a year, using only what you left behind?

Not "could they understand your design." Could they diagnose the four failure modes, migrate a model, tell whether a change made things worse, and know what the system is not supposed to do.

If the answer depends on someone remembering to ask you something, you have not handed over. You have created a dependency and left.

Try this today — 40 minutes

Take the system you are currently closest to — client-delivered or internal — and write the symptom-first runbook. Not the architecture. Ten symptoms.

Format: what someone would observe → the first thing to check → where to look.

Then do the honest test on it. Give it to someone who did not build the system and ask them to walk through one symptom out loud. Watch where they stop.

The place they stop is your actual handoff gap, and it is almost never where you expected. Most people discover the gap is not technical — it is that the reader does not know where something lives, or does not have access to look.

Related: Scoping an FDE engagement · When the client's data is worse than they said · Documenting your Claude setup for client handoff · When your AI model disappears