Every agency says they ship production software. Almost every project still arrives as something closer to a demo — working, impressive in a walkthrough, and quietly held together by conditions nobody wrote down. It’s worth being concrete about the difference, because the gap is where most budgets disappear.
A demo optimises for the happy path
A demo needs to work once, on a prepared account, with clean data, in front of someone who wants it to succeed. That’s not dishonest — it’s what a demo is for. The problem starts when a demo gets promoted to production without anyone paying the difference.
What a demo is usually allowed to skip: bad input, concurrent users, expired sessions, partial failures, timeouts, the third-party API being down, someone hitting the back button mid-flow, and the specific customer whose data breaks an assumption you didn’t know you’d made.
Production is defined by its unhappy paths
Software in production is judged on what it does when things go wrong, because at any real volume, things go wrong constantly. The list is boring and it is the entire job:
- It fails visibly, not silently. A failed payment, a dropped webhook, a stalled import — someone is told, and someone can retry it.
- It is observable. When a user says “it didn’t work,” you can find out what happened without guessing.
- It handles the second user. Two people doing the same thing at the same time is a real case, not an edge case.
- It can be deployed on a Tuesday afternoon. If releasing is scary, you’ll release rarely, and every release will be big and risky.
- It can be handed over. A new developer can set it up, understand it, and change it without a phone call.
The three things that make the difference cheap
Closing the demo-to-production gap is not a matter of heroic effort at the end. It’s three habits applied from the start, each of which is cheaper than the rework it prevents.
Ship to production from week one
Not the whole product — the first thin slice, live, behind a flag. The first deploy is where you discover the environment differences, the auth quirks, and the DNS mistakes. Doing that in week one costs a day. Doing it in the final week costs the launch date.
Make the boring parts real early
Error handling, logging, and the deploy pipeline are the parts most tempting to defer and most expensive to retrofit. They’re also what makes every later slice faster to build, because you stop debugging by guesswork.
Let real users touch it before it’s finished
Real users find the assumptions you can’t see. Every week they’re kept away is a week of building on unverified guesses.
What this looks like from the client side
You should be able to open a URL and use the thing, in production, within the first couple of weeks — small, incomplete, but genuinely live. From then on it should get bigger every couple of weeks. If the first thing you see is a video, a click-through prototype, or a staging link that mysteriously can’t take real data yet, you’re watching a demo, and the production work is still ahead of you and probably not in the budget.
The honest version of this promise is also a constraint on us: shipping in slices means less room to hide, and each slice has to survive contact with reality before we get to build the next one. That’s the point.
