The Gap Between a Working MVP and a Production System

“It works. We just need to productionise it.” That sentence has launched more doomed timelines than any other in software.

The MVP works in the demo. It works for the founder clicking through the happy path. And from there, “just productionising it” sounds like a week of tidying up. It is not. The gap between a thing that works and a system you can run for real customers is wide, and it is invisible from the demo, which is exactly why teams walk off the cliff.

The MVP proves the idea. Production proves you can operate the idea when things go wrong, at volume, with money and reputation on the line. Those are different jobs.

An MVP Answers One Question. Production Answers Twenty.

An MVP exists to answer a single question: does this solve the problem for a user who does exactly what we expect? That is a legitimate and valuable thing to prove, and cutting corners to prove it fast is correct.

Production has to answer a much longer list. What happens when two users do the same thing at once? What happens when the input is malformed, malicious, or enormous? What happens at 3am when the founder is asleep and something breaks? What happens when the database fills up, the third-party API goes down, or traffic spikes tenfold overnight? The MVP never had to answer these, because in a demo none of them happen. Production is nothing but these questions.

Where the Gap Actually Lives

The distance is not in the features. It is in everything around the features—the parts a demo never exercises.

Failure Handling

In the demo, the payment succeeds, the email sends, the upload completes. In production, all of these fail routinely, and the question is what happens next. Does the user see a helpful message or a stack trace? Does a failed payment leave the order in a broken half-state? MVP code typically assumes success. Production code assumes failure and handles it gracefully. Retrofitting that assumption touches almost every line.

Concurrency and Data Integrity

One user is a simple system. Many simultaneous users create races, deadlocks, and corrupted state that never appear in single-user testing. The classic case: two people buy the last item at the same moment and both succeed. MVPs almost never handle concurrency correctly because the demo never has concurrency. Making the data model safe under load is quiet, unglamorous, essential work.

Observability

When the MVP breaks, you reproduce it on your laptop. When production breaks, you have logs, metrics, and traces—or you have nothing and a very bad afternoon. The ability to answer “why did this fail for this user at this time” is not a feature the customer sees, but without it you are operating blind, and it has to be built in, not bolted on.

Security and Cost at Scale

A demo has no attackers and no bill worth mentioning. Production has both. The authorisation shortcut that was fine for a founder testing their own account becomes a data breach when it faces the internet. The unindexed query that was instant on ten rows becomes a runaway cloud bill on ten million. These are not edge cases in production—they are the main event.

Why Teams Get the Estimate So Wrong

The gap is systematically underestimated for a simple reason: the demo is the only evidence anyone has, and the demo shows the ten per cent that was easy while hiding the ninety per cent that is hard. The founder sees a working product and reasonably assumes it is nearly done. The engineer who built it may believe the same, because building the happy path felt like the substance of the work.

It was not. In most systems, getting to a working demo is a fraction of the total effort. The rest—failure handling, concurrency, observability, security, the operational scaffolding—is the larger part, and it is precisely the part that does not show up in a click-through. Calling it “just productionising” makes it sound like polish. It is foundation.

Crossing the Gap Deliberately

The answer is not to over-engineer the MVP—that defeats its purpose. The answer is to be honest about which stage you are in and to cross the gap on purpose rather than by accident.

Keep the MVP lean while it is still proving the idea. But the moment you decide to put real customers on it, treat that as a distinct phase of work with its own real budget, not as a rounding error at the end of the MVP. Harden the critical paths first—the ones that touch money and data. Add observability before you need it, not during the outage. And bring senior judgement to the question of what can break and what it costs when it does, because that judgement is the entire difference between a demo and a system.

The MVP earns you the right to build the real thing. It is not the real thing. Teams that understand that distinction ship products that survive their own success. Teams that don’t discover the gap the hard way—usually right after the launch that was supposed to be the good news.

---