The Invisible Half: What Lies Between Demo and Production

There’s a moment in almost every software project that feels like the finish line but isn’t. The demo runs. The client nods. Someone says the words: “Basically it’s done, we just need to go live.”

That sentence is almost always wrong. Not because the demo is bad — but because “just go live” hides an entire discipline inside four words.

What Does a Demo Not Have to Prove?

A prototype has one comfortable property: it’s allowed to fail without it counting. It runs on one machine, under supervision, with hand-picked inputs, once. If something hangs, you restart. If an edge case shows up, you ignore it.

Production gets none of that. It runs unattended, with inputs nobody anticipated, in parallel, continuously. It will fail eventually — the only question is whether anyone finds out before the client calls.

The gap between these two states is the invisible half of the work. It’s invisible because nothing in that half adds anything you could show in a demo. It only becomes visible when it’s absent.

What Does the Invisible Half Actually Contain?

The invisible half consists of four building blocks that take a system from “it works” to “it holds”: observability, migration discipline, deploy smoke tests, and incident runbooks. None of them are visible in a demo — which is exactly why none of them get planned for.

Observability. Logs, metrics, trace IDs. Not for their own sake, but so that when an incident happens, one question has an answer: what occurred, in what order, on which request? A system without observability gets debugged by guessing. Guessing is slow, and slowness in an incident is expensive.

Migration discipline. Database changes must be linear, traceable, and — where possible — reversible. A migration that locks a large production table isn’t a technical detail. It’s an outage. The difference between a safe migration and a dangerous one is never visible in the demo phase, because the demo database is empty.

Deploy pipelines with real smoke tests. A green build image proves the code compiles. It doesn’t prove the application starts, that it can reach its database, or that the core user flow still responds. A smoke test that checks exactly that — a real endpoint, a real response — is the last line of defense before the client notices.

Runbooks for when things go wrong. The moment something is burning is not the moment to figure out how to roll back. A rollback runbook, an incident procedure, a clear answer to “who decides” — these have to exist beforehand. In an incident, nobody has time to invent them.

Why Does This Get Lost in Planning?

The invisible half is systematically underestimated, and the reason is structural. Effort gets estimated against what can be demonstrated. A feature is visible, so it gets scheduled. Observability is invisible, so it gets “done on the side.” Until it isn’t.

My counter to this is simple: production-readiness belongs in the same estimate as the feature, not in a later one. When a scope gets quoted as “two weeks,” I ask whether those two weeks include safe migrations, logging in place, and a deployment smoke test. If the answer is no, then it’s not two weeks — it’s two weeks to the demo. That’s a different statement.

The Honest Sentence at the End

“It works” and “it holds” are two different states. Between them lies work that nobody sees and that nonetheless determines whether you get a congratulatory email or a support call at midnight.

Someone who accepts a demo as the goal has bought half the journey and believes they’ve arrived. The second half comes regardless — either as planned work before launch, or as an unplanned emergency after. Planned is cheaper.