The Prototype to Production Checklist: From Demo to Dependable

Friday, 4 p.m. You demo the dispatch tool to the ops team and it goes perfectly. The map loads, jobs drag and drop onto drivers, the CEO says this is great out loud, twice. Someone applauds. Actual applause, in a conference room, for software.

Monday, 8:15 a.m. The ops lead appears at your desk with the question that ruins your week: can the whole dispatch team start using it today? Forty people. Real customers. Real trucks. This is the moment you want a prototype to production checklist, and you do not have one yet. You smile and say sure, because you are an optimist, and then you feel the cold sweat arrive precisely on schedule.

What follows is that checklist: the twelve things that separate a demo people applauded from software people rely on. None of them are glamorous. All of them are cheaper than the alternative, which is finding out about them in production, in public.

A demo proves possibility; a product survives reality. The distance between the two is a short list of unglamorous work: real authentication, backups you have actually restored from, error states that do not lie, and capacity for one more user than you planned for. Budget two weeks of hardening, not two months of rewriting, and skip the scale theater until you actually have scale.

The Demo That Worked Too Well

Understand why the demo worked, because it was not a fluke. It had one user, you, who knew exactly where to click. It had seed data: twelve tidy jobs, four drivers, zero edge cases. It ran on your laptop, on your Wi-Fi, down the hall from the people applauding. The demo did not lie. It testified under ideal conditions, which is what demos are for.

The gap from demo to production is not a condemnation of the prototype. The prototype did its job: it proved the idea deserves to exist. If you built it following a rapid prototyping playbook, you even did it fast. Now the idea has to survive contact with forty dispatchers who did not attend the demo and will absolutely click the wrong thing.

There is a version of this story where the founder says yes on Monday and ships the demo as-is. It usually takes about nine days before something real breaks: a deleted route, a shared password in a screenshot, a morning where the tool simply does not load and forty people stand around a whiteboard like it is 2009. The checklist below is how you get to say yes without collecting those stories.

The Short Answer: A Demo Proves Possibility, a Product Survives Reality

Here is the part that surprises people: production readiness is mostly not rewriting. The code that wowed the room usually ships nearly unchanged. What changes is everything around it: who can log in, what happens when it falls over, where the data goes when someone fat-fingers a delete. You are not rebuilding the house. You are installing locks, a sump pump, and a number on the door.

The Prototype to Production Checklist: The Twelve Things

Twelve items, four groups. Each one is a single line of work, and each one comes with the failure story it prevents.

People and Access

1. Real authentication. Individual logins, no shared password. The demo's admin-admin login is about to live in forty browsers, one of which belongs to a contractor whose last day was in March.
2. Roles and permissions. Dispatchers edit; drivers view. The first time a driver deletes Tuesday's route, you will suddenly care deeply about roles.
3. Offboarding. People leave; their access should leave faster. Every company has a story about an ex-employee still logging in to check on things.

Data and Disasters

4. Backups with a tested restore. A backup you have never restored from is a hope, not a backup. Do the restore drill before you need it.
5. Migrations. A boring, repeatable way to change the schema without deleting the production database at 9 a.m. on a Tuesday. Ask a friend how they know this one.
6. Audit trail. Who changed what, and when. The first disputed invoice or vanished job pays for this feature entirely.

Reality and Load

7. Error states. What the user sees when things fail. Something went wrong, here is a reference number beats a silent spinner or, worse, a stack trace with your database name in it.
8. One more user than planned. Load test at twice the expected headcount. The demo had one user; reality has forty dispatchers and a board member who wants to poke around.
9. The 3 a.m. question. When it breaks at night: who gets alerted, what they do, and how the system recovers. Restart and hope is a strategy, briefly.

Money and Time

10. An owner. One named human whose job includes this tool. The team owns nothing; that is how tools become orphans.
11. Run cost. What it costs per month at real usage, written down. Cost surprises end tools faster than bugs do.
12. Kill criteria. Decide in advance what usage or value justifies keeping it alive. Otherwise you get undead software: maintained forever, loved by no one.

What You Can Safely Skip

Now the honesty section, because production readiness is not the same as enterprise cosplay. Skip multi-region failover. Skip Kubernetes. Skip microservices, SOC 2, and the status page with five-nines language. Forty dispatchers in one metro area do not need a service mesh. They need the backups from item four.

Scale theater feels responsible and is actually the opposite: it spends your two weeks rehearsing for a load you do not have while the load you do have walks in through an admin-admin login. Any honest MVP launch checklist fits on an index card; the enterprise edition can wait for the enterprise. If your Wizard-of-Oz prototype had a human behind the curtain, this is also the moment the human has to leave; hardening means the system works when nobody is secretly holding it together.

A useful test for any skip-or-build question: does this protect the users we have this month, or the users in a pitch deck? Build for the first group. The second group can wait for their infrastructure, and honestly, they enjoy waiting.

The Two-Week Hardening Plan

Here is the prototype to production checklist turned into a calendar. Days one through three: authentication, roles, offboarding, and the backup with an actual restore drill. Days four through seven: error states, audit trail, and your migration path. Days eight through ten: load testing with real-ish volume, meaning you replay a genuine week of dispatch data at double speed and watch what smokes. Days eleven through fourteen: the runbook, the ownership doc, the handover, and one rehearsal of the 3 a.m. call so the first time is not the first time.

One more trick: your next stakeholder demo should be scripted to set up V1, showing the hardened boring parts alongside the shiny ones, so Monday's question never ambushes you again.

Monday-you said sure. Two weeks from now, it will be true, and the next demo ends with a launch date instead of a cold sweat.