You made the call to bring development in-house. Good call — at your stage, owning the engineering usually beats renting it. Then the agency's "handover" arrives: a link to a Git repository, a single README that says npm install && npm run dev, and an email that ends with "let us know if you have any questions." You forward it to your two newly hired engineers, who clone the repo, and within an hour they're in your office with the same expression. They can't run it locally. They don't know which of the forty environment variables matter. They have no idea why a critical piece of code does what it does, and the only person who knew is now off your account.
This isn't a handover. It's an abandonment with extra steps. A repo is the artifact; a handover is the transfer of the ability to operate that artifact safely, and those are wildly different things. The gap between them is where your new team spends three months reverse-engineering a system instead of improving it, and where a routine change accidentally takes down production because nobody documented the landmine.
What a fake handover costs you
The cost isn't theoretical and it isn't small. It shows up in three places.
Ramp time. Two engineers reverse-engineering an undocumented codebase — figuring out the architecture, the deploy process, the why behind decisions — burn two to four months before they're shipping confidently. At $15k per engineer-month, that's $60k to $120k of salary spent on archaeology that a proper handover would have compressed to weeks.
The first self-inflicted outage. Somewhere in that codebase is a piece of undocumented critical knowledge — a deploy step that must run in a specific order, a service that can't restart without a manual action, a migration that locks a table. Your team, not knowing, trips it. The first major incident after an in-house transition is frequently caused by the transition itself, and it lands while your team is least equipped to handle it.
Vendor lock-back. The cruelest one: the handover is so thin that you have to keep paying the agency for "support" because they're the only ones who understand the system. You moved development in-house to stop paying them, and now you're paying them more, as an emergency dependency, on worse terms. A bad handover doesn't end the relationship — it converts it into a hostage situation.
A real handover costs a fraction of any one of these. The math is not close.
A repo and a zip is not knowledge transfer
Here's the distinction that matters. The agency has two things: the code, and the context that lives in their heads. The code is easy to transfer — it's already in Git. The context is the entire value, and it's exactly what a "here's the repo" handover leaves behind.
Context is: why this database is structured this way and not the obvious way. Which parts of the code are load-bearing and which are dead. Where the bodies are buried — the hack that's holding up a critical flow, the integration that's flaky, the thing you must never touch on a Friday. The deploy sequence that isn't written down because "everyone knew it." A handover that doesn't extract this is handing your team a map of the streets with none of the warnings about which bridges are out.
The test is simple: after the handover, can your team deploy a change to production, on their own, without calling the agency? If the answer is no, you didn't get a handover. You got a repository and an invoice.
The documents that actually matter
You don't need a thousand pages. You need a specific, small set of documents that capture operational reality, not aspirational architecture diagrams.
The setup runbook. A new engineer goes from nothing to running the system locally by following written steps, with no tribal knowledge required. Every environment variable explained — what it is, where to get it, whether it's optional. If a fresh laptop can't get to a running app from this document alone, it's incomplete, and you test it by having someone who's never seen the code actually do it.
The architecture overview. Not a beautiful diagram — a true one. What the major pieces are, how they talk, where the data lives, which external services it depends on, and crucially, why the big decisions were made. The reasoning is what lets your team change things without breaking the assumptions they didn't know existed.
The deploy and operations runbook. Exactly how code gets to production, step by step. How to roll back. How to run a migration safely. What to do when the common failures happen. This is the document that prevents the first self-inflicted outage.
The "here be dragons" list. The single most valuable and most-often-missing document. An honest inventory of the known landmines: the fragile integration, the part with no tests, the manual step everyone forgets, the thing that's technically debt but holding up revenue. A vendor genuinely doing right by you writes this one. A vendor protecting future support revenue conveniently forgets it. Demand it explicitly.
Access and accounts. Every service, credential, domain, and account the system depends on, transferred into your ownership — not the agency's accounts you're borrowing. This is mechanical and boring and it's where teams get stranded six months later when a renewal fails on an email nobody controls.
The 30-60-90 transition
A handover isn't an event, it's an overlap. The pattern that works is a phased transition where responsibility shifts gradually while the agency is still reachable.
Days 0–30 — your team operates, the agency observes. Your engineers do the work — fix a real bug, ship a small feature, run a deploy — with the agency available to answer questions. The goal isn't speed; it's surfacing every gap in the documentation by hitting it in practice. Every "wait, how does this work" is a hole you fill while the people who know are still on the phone.
Days 30–60 — your team owns, the agency advises. Your engineers are now the primary owners. The agency's role shrinks to occasional consultation on the genuinely hard stuff. You're deliberately stress-testing whether the knowledge actually transferred, by living without the safety net for routine work.
Days 60–90 — full independence, agency on call. Your team runs everything. The agency is a paid escalation path for true emergencies only, and you're measuring how often you actually need them. If the answer trends to zero, the handover worked. If you're calling weekly, the transfer was incomplete and you address it now, while there's still a relationship to lean on — not in month seven when they've moved on.
The reason this is phased and not a clean cut: you cannot know what knowledge is missing until you try to operate without it. The overlap is what converts "I think we have everything" into proof, on a timeline where gaps are still cheap to fix.
If the codebase you're inheriting is genuinely a mess — undocumented, fragile, and the agency relationship has already soured — the handover may need to become a rescue. We've taken over exactly these systems and turned them into something an internal team can safely own. See how we approached it →
What fixed looks like
Fixed is your two new engineers cloning the repo, following a setup runbook, and having the system running locally before lunch — then shipping a real change to production by the end of week one, without calling anyone.
Fixed is an honest architecture overview that explains the why, a deploy runbook that prevents the self-inflicted outage, and a "here be dragons" list that tells your team exactly where not to step. Fixed is every account and credential in your name, so a renewal never strands you. Fixed is a 30-60-90 overlap that proved the knowledge transferred instead of assuming it.
Most of all, fixed is the agency relationship ending when you decided it should — cleanly, with your team fully in control — instead of mutating into an expensive permanent dependency.
This is for you if
You're bringing development in-house and you either got a thin handover already or you want to make sure you don't. We run real handovers and rescues — extracting the context, writing the documents that matter, and structuring the 30-60-90 so your team actually ends up independent. Auditing an inherited codebase and producing the missing operational docs typically starts at $25k+; a full takeover where we stabilize a fragile system and document it for your team runs $50k+; $100k+ when it's a genuine rescue of a large, undocumented codebase plus hands-on transition support for your new hires.
This is not for you if your outgoing vendor did a thorough job — complete runbooks, a dragons list, transferred accounts, an overlap period — in which case you have what you need and should just execute. It's not for you if your internal team is already deep in the codebase and shipping confidently; the transfer already happened. And it's not for you if you want a one-page summary to feel covered without the operational documents and the overlap that actually prevent the outage and the lock-back. That document is the thing that looks like a handover and isn't — and it's exactly what landed in your inbox.