Build it, then run it: why most technology handovers fail

Most technology projects are structured around a handover. One team designs and builds the system. When it’s “done,” they hand it to a second team — often a different company — to run. Everyone treats that moment as the finish line.

It’s usually where the trouble starts.

The knowledge that never gets written down

A working system carries a large amount of undocumented context: why a queue was sized the way it was, which failure the retry logic is really guarding against, what the odd-looking config on a Tuesday night is for. The people who built it hold that context in their heads. A handover document captures maybe a tenth of it.

So when something breaks at 2 a.m. six months later, the team on call is debugging a system they’ve never reasoned about, using notes that were out of date the week they were written. The incident lasts longer than it should. Trust erodes. And the fix, made under pressure by people without the full picture, often stores up the next problem.

Accountability follows ownership, not contracts

You can write reliability targets into a contract. You cannot write in the judgement that keeps a system reliable in the first place. That judgement comes from having skin in the game — from knowing that if you cut a corner today, you’re the one carrying the pager when it gives way.

When the team that builds a system is also the team that runs it, the incentives line up. Decisions get made with the full lifetime of the system in view, not just the launch date. Shortcuts that look cheap at build time and expensive at run time simply don’t get taken, because the same people pay for both.

What we do instead

We don’t hand over. We build systems and then operate them, with the same people accountable across both. That changes how we work from day one:

• We design for the 2 a.m. case, not the demo. Observability, sensible defaults and clear failure modes are part of the build, not a later add-on.
• We keep the team small and senior. Fewer people means less context lost in translation, and more of it held by people who can act on it.
• We stay measurable. We agree what “healthy” means up front and report against it honestly — including when we miss.

None of this is exotic. It’s just what happens when you stop treating the handover as someone else’s problem.

The honest trade-off

Running what you build is harder to sell than a fixed-scope project with a clean exit. It asks for a longer relationship and more trust on both sides. But for systems a business actually depends on, it’s the only model we’ve seen that holds up — because the accountability doesn’t get handed away with the code.