The Bill Arrives After the Applause

The room was genuinely excited. The prototype worked, the pilot metrics looked good, and someone said the words every lab lives for: "let's put this in front of real users."

Eight months later, the same tool is a channel called #help-toolname where forty people post screenshots of broken exports. There's no on-call rotation. The original builder moved to a different team in March. The vendor contract was signed on a personal card and nobody remembers the login. A security review got scheduled twice and cancelled twice.

Nothing failed, exactly. That's the problem. Success is a fork in the road, and most labs are only equipped for the branch where the experiment dies.

Two Endings, One of Them Planned

Every experiment resolves one of two ways. It dies — and if you built it with an expiration date, that's a clean, cheap, dignified ending. Or it lives, and living is expensive.

The strange part is that we celebrate the expensive outcome and quietly treat the cheap one as a failure. But a prototype that dies on schedule has cost you exactly what you budgeted. A prototype that survives has just taken on a second life you never scoped.

The Four Bills That Show Up Late

The support bill

Nobody staffs a support desk for a lab project. So support happens in DMs, in hallways, and in a channel where the builder answers questions between their actual job. That works for about six weeks. Then the builder goes on parental leave and forty people discover they've been depending on a person, not a system.

The security bill

The prototype authenticated with a shared password and stored files in someone's drive. Fine for a demo. Not fine for something that now holds customer data. Suddenly you need an access model, a retention policy, a review, and probably a conversation with legal about which compliance scope this thing just expanded.

The ownership bill

"Who owns this?" is a question people ask during incidents, not during launches. If the answer is a team name rather than a person, you don't have an owner. You have a rumor.

The opportunity bill

The builder is now a maintainer. Every hour spent on bug triage for the successful experiment is an hour not spent on the next one. Labs that don't account for this slowly convert their best explorers into unpaid sysadmins and then wonder why the pipeline dried up.

Why Nobody Plans for This

Incentives, mostly. Labs get funded on launches and demos and pilot readouts. Nobody puts "successfully handed off to an operations team that didn't want it" on a slide.

There's also a psychological wrinkle: planning for maintenance feels like doubting the experiment. Teams avoid the conversation because it sounds like betting against yourself. In practice it's the opposite — the experiments that get to keep going are the ones somebody bothered to make sustainable.

Write the Exit Plan at Kickoff

Handoff documents written at the end of a project are考古 — sorry, archaeology. The people who knew the context have moved on, and the reasoning has decayed into "we think it was for the reporting thing."

Write the exit plan in week one, when everyone still cares and the answers are cheap:

• Name a likely receiving team before you write code. Not a commitment — a conversation. If no team could plausibly own this, that's a finding, not a detail.
• Define "done" to include operations. A runbook, a monitoring story, a named owner, and a support tier. If those aren't in the definition of done, they aren't going to happen.
• Set a maintenance budget line early. Ongoing support costs a meaningful fraction of what it took to build, every year, and someone has to pay for it. Decide who before the pilot ends, not after the first outage.
• Schedule a 90-day keep-or-kill review. Success at launch predicts almost nothing about month six. Put a review on the calendar while the tool is still small enough to shut down gracefully.
• Decide what happens to the builder. Do they stay attached as an advisor for a set number of hours a week? Hand it off entirely? Both are legitimate — the failure mode is leaving it ambiguous.

The Handoff Is a Launch Too

Handing a working tool to another team is a product launch with a hostile user base, because the receiving team just inherited a pager they didn't ask for. Treat it like one: training, documentation, a named counterpart, a transition period where the original builder is reachable, and public credit for the people taking it on.

And say the quiet part out loud in performance conversations. Maintenance is real engineering work. If the only way to get recognized is to ship something new, you've built a system that punishes the exact behavior you need.

Sometimes the Right Answer Is to Kill It

A pilot can succeed technically and still have no viable home. When that happens, shutting it down on purpose — with a written record of what you learned and who you learned it from — is a better outcome than letting it drift into unpaid operation.

Deliberate shutdowns are cheap. Zombie projects are not.

The applause is fine. Enjoy it. Just have the paperwork ready before the room empties, because the bill doesn't care how good the demo was.