What a good handoff actually looks like

The last week of an automation project tells you more about an agency than the first month. Anyone can ship a working system. Fewer can hand it off in a state where the client's own team can operate it, extend it, and fix small things without calling back. That gap is where a lot of long-term client relationships quietly sour: the automation works, but the client feels like a hostage to it.

What handoff usually looks like, and why it's not enough

A repo link and a thirty-minute call. Maybe a README that was accurate the day it was written. The client nods along in the call, understands maybe half of it, and then six weeks later something needs a small change and they're back on the phone, because nothing about the handoff actually transferred understanding, just access.

What we actually hand over

• A plain-language runbook: what runs when, what to check if something looks wrong, written for the person who'll actually own it, not for a developer.
• Credentials in the client's own accounts, not ours, set up during the build, not migrated at the end under time pressure.
• A recorded walkthrough of the actual system running, not slides about it, that a new hire can watch in six months.
• A short list of 'things that will probably need to change next year' so it's not a surprise when they do.

If the client can't survive you going on vacation, the project isn't done, regardless of what's in production.

It changes how you build, not just how you end

Knowing the handoff has to be real changes decisions made in week one. It pushes you toward boring, documented, standard tooling over the clever one-off script that only makes sense to the person who wrote it. That tradeoff, slightly less elegant for slightly more maintainable, is almost always the right one when someone else has to own the result.