5 min read
Handover is part of the build
The system still has to make sense if the people who built it aren't answering Slack.
Written by OZP Studios, Seattle, WA
We're a small team. That isn't a reason to skip the boring part — it's why we treat handover as part of the build, not a week of docs at the end. If the system only works while someone on our side is answering Slack, we didn't finish.
Clients aren't hiring a studio so they can keep us on call forever. They're hiring us to leave software a competent stranger can run. Kyle Fukuda runs delivery. Kyle Huynh still writes a lot of the code. If the only way to change a copy string is to ping one engineer, that's still our problem, even after the invoice is paid.
What we actually hand over
The list is boring on purpose. Boring is the point.
- A repo that installs. Not a zip of the last working folder.
- Env vars in one place, including the ones that will wake someone up if they're missing.
- The decisions that aren't in the code: why this vendor, why this auth model, what we tried and threw out.
- Access that isn't tied to a personal Gmail.
- A short path for the next person. If you need to change X, start here.
We write that while the work is still in our hands. Documentation produced in the last three days of a contract is a souvenir. Documentation written when we still remember why we hated the first approach is the stuff people actually use.
What doesn't count
A 40-page PDF nobody opens. A Loom of someone clicking the happy path. “We'll always be around.” We might be around. That can't be the architecture.
We've seen teams treat the studio as a backup brain. It feels efficient until someone is on a plane, or sick, or the engagement is over. Then the product is a black box with a nice UI, and the next person has to reverse-engineer why auth works the way it does.
Staying is a different job
Good handover makes it easier not to need us. That's uncomfortable to say out loud if you sell ongoing work, but it's the point. Ongoing support is a separate engagement with a scope — not a vague leftover from the build.
If you want us to stay, say so, and we'll price the staying. If you want to take it in-house, we should spend time on the transfer instead of another feature you won't be able to touch. Either is fine. Mixing them — building as if we'll always be there, then leaving — is how projects rot.
Build until it can leave. Stay only if you asked us to stay.