We see the same misunderstanding across startups and enterprises alike: a working demo that compiles is treated as a product. It is not. It is a prototype, and mistaking the two is one of the most expensive errors in software.
What a prototype is for
A prototype exists to answer one question: does anyone want this? It should be cheap, throwaway, and optimistic. It is judged by signal, not by architecture. If it works 'well enough,' you have your answer.
- One bold assumption per prototype. Everything else can be stubbed.
- Hard-coded data over integrations. Real data hides real questions, but not yet.
- No auth, no scale, no observability beyond what the demo needs.
- A clear expiry. Agree in advance when the prototype dies.
What production is for
Production exists to be depended on. It is judged by entirely different criteria: upgrades, on-call, data loss, security, and the people who will maintain it after the launch party. These properties cannot be bolted on.
A prototype convinces people a product is possible. Production is what survives contact with real users.
The seam between them
The discipline is refusing to evolve the prototype. When validation succeeds, step back, write the short product spec that the demo implied, and build the production system fresh with that spec in hand. It feels wasteful for a week and pays for itself for years.