The test we use

A month after the final invoice, can the client's own team — without calling us — do three things?

  • Run the workflow end-to-end on a new piece of real input.
  • Notice that it has broken, or is about to, before a customer does.
  • Either fix it themselves, or hand it to a different supplier, without starting from scratch.

If the answer to any of those is no, the engagement was not finished — we just stopped billing for it.

What the handover package contains

A handover is not a debrief meeting. It is a set of artefacts the client can still read in six months when they have forgotten everything we discussed. We deliver four of them.

1. Credentials, in the client's name

Every account, subscription, and API key is created under the client's email address, billed to the client's card, and owned by the client from day one. We are given delegated access for the duration of the engagement and revoked at the end. We never set up a workflow against our own OpenAI or Anthropic account and then re-bill for usage — that model is easier to start and ruinous to exit.

The credential inventory is a single document listing every account, who owns it, how to rotate its key, and what happens if the key is revoked. It lives in the client's password manager, not in email threads.

2. Runbooks for the three things most likely to break

Not general documentation. Three specific runbooks, each fitting on a page, for the failures we have actually seen in the engagement: API rate-limited, model output off-shape, and input source changed format. Each runbook has the symptom, the diagnosis step, and the fix — written for someone who has not touched the workflow in a month.

The temptation is to document everything; the discipline is to document the three things that cover eighty per cent of real incidents. If the runbooks try to be comprehensive, no one reads them when something breaks.

3. A monitoring setup that is boring

Boring means two things. First, it uses tools the client already pays for — usually email alerts or a free tier of a generic monitoring service — rather than a bespoke dashboard that requires a licence we chose. Second, it alerts on outcomes, not components. "The workflow has not produced output in 24 hours" is an actionable alert. "API latency is in the 98th percentile" is noise unless the client has someone whose job is to read it.

A handover with a bespoke dashboard that only we know how to operate is not a handover. The client inherits an obligation to keep us on retainer forever, which is exactly what we are trying to avoid.

4. An exit ramp

This is the artefact clients are most surprised to receive. It is a one-page document explaining how to replace us — which components are standard and portable, which are specific to our choices, and what a reasonable transition to another supplier or to in-house would look like.

Writing it is uncomfortable the first time. It is also the thing that, more than anything else, convinces clients we were worth the engagement. A supplier confident enough to document their own replaceability is in short supply.

What we remove from the handover

Three things we deliberately do not leave behind, and why:

Our proprietary templates, as literal files. The client gets the prompts that run their workflow, not our library of templates from other engagements. Shipping the library creates a dependency on our ongoing updates; shipping the running prompts lets the client evolve them without us.

Credentials to anything we own. No shared service accounts, no access to a monitoring service we happen to pay for, no keys that would stop working if we forgot to renew a licence. Every external dependency routes through the client's own accounts.

Optional integrations. If we built something during the engagement that was not strictly required — a nice-to-have integration, an internal dashboard, a slack bot — it either gets cut from the handover package or is explicitly marked as optional and unsupported. Clients should not inherit maintenance responsibility for work they did not ask for.

The post-handover check-in

Thirty days after the final invoice, we send one email asking three questions: has the workflow run without intervention, have the runbooks been used, and is there anything that was unclear. The answers usually fit in a paragraph. We do not charge for this, and we do not use it as a sales hook.

It exists because if something is broken, we want to know — not to sell a support retainer, but because the engagement is not really over until the workflow has survived a month of real use in our absence. A handover that passes that test is the outcome we are selling.

— Zheng Zhong, Founder, SOLO TECH LTD