Here’s a question that separates a good engineering partner from a bad one in about ten seconds: ask them what happens if you want to leave. If the answer is vague, or the room gets a little tense, you have your answer already. At orithLabs, we send a handoff document before we send an invoice for the milestone it documents — not after a breakup, not on request, as a default part of how we work.
We built this habit because we’ve seen the alternative up close. Founders come to us holding a codebase they paid tens of thousands of dollars for, and nobody on their team can tell them how the pieces fit together, who has access to what, or why a particular decision was made six months ago. The original developers are gone, unreachable, or quoting a large sum to “get back up to speed.” That’s not a technical failure. It’s a documentation failure, and it’s entirely avoidable.
What’s Actually In It
The handoff doc isn’t a slide deck or a status update. It’s three specific things, written so a competent engineer who has never spoken to us could pick up the project cold.
- Architecture notes. Not a generic diagram — the actual shape of your system as built. How the mobile app talks to the backend, where the state lives, which services are third-party and which are ours, and where the sharp edges are. If something is held together with a workaround because a proper fix needs a future migration, that’s written down, not hidden.
- A decision log. Every non-obvious call gets a one-paragraph entry: what we chose, what we didn’t, and why. Why Flutter instead of two native codebases. Why a particular data model instead of a simpler one that wouldn’t scale. Why we skipped a feature request for now. Six months later, when someone asks “why does it work this way,” the answer isn’t a shrug — it’s a line in a document.
- An access checklist. Every account, repository, API key, domain, and third-party service tied to the project, who currently holds credentials, and what needs to be transferred or rotated. This is the part most agencies quietly skip, because ambiguous access is a soft form of lock-in. We’d rather hand you a clean list than make ourselves hard to route around.
Why We Do It Before the Invoice, Not After
Sequencing matters more than it sounds like it should. A handoff doc written after a client asks to leave reads very differently from one written as a routine part of delivery — it tends to be defensive, incomplete, and produced under pressure. Writing it before billing forces a different discipline: if we can’t explain a decision clearly enough to put it in the log, that’s usually a sign the decision itself needs another look, not just the writeup.
It also changes the incentive structure, which is really what founders are worried about when they ask “why you and not a freelancer or a bigger agency.” A freelancer’s income depends on being the only person who understands the code. A large agency’s retainer depends on you not having the leverage to leave. Neither of those setups rewards clear documentation — quite the opposite. We’re two engineers who’d rather compete on the work being good enough that you’d choose to keep working with us, not on you being unable to figure out how to leave.
What This Looks Like in Practice
On apps we’ve shipped, like Crumb Count and Kompete, this meant the architecture notes and decision logs existed before either app was in front of real users — not retrofitted for a case study. It’s the same document whether the client reads it closely or files it away and never opens it. Most don’t need it immediately. The ones who do — because they’re bringing engineering in-house, switching vendors, or just want a second opinion on the code — are exactly the founders this protects.
If you’re currently mid-negotiation with a studio or freelancer, ask to see a sample handoff doc from a past project before you sign anything. Not a description of their process — the actual artifact, redacted if needed. If they can’t produce one, that tells you what their business model depends on.
We treat this as table stakes, not a differentiator we should be shy about. If you’re evaluating whether to unstick a stalled build, bring in outside help for a code audit, or start something new, feel free to ask us what a handoff doc looks like for a project like yours — we’re happy to walk through one before you’ve committed to anything.