The demo is not the product
Why the prototype that dazzled on Thursday dies on Monday, and what actually changes in between.
A demo is a stage performance. One user, clean data, the person who built it driving, and a script that has been rehearsed. It can be a genuinely good performance — and it tells you almost nothing about what happens next.
The product is the same software with the playwright gone. Different people use it at the same time. Data arrives wrong. Someone pastes a 40,000-row spreadsheet where a date should go. It’s the last day of the month and the payment provider has an incident. None of this is bad luck. It’s just the part the demo didn’t include.
What changes between Thursday and Monday
Four things, mostly.
Other people. A demo has one user. A product has many, at once, with different jobs, on their worst day. Software that never planned for concurrency, permissions, or the intern who clicks everything will meet all three in its first week.
Bad inputs. Real data is late, duplicated, misspelled, and occasionally hostile. The demo used the good spreadsheet. The product gets the real one, every day, forever. Every field you didn’t validate is a support ticket you haven’t received yet.
The neighbors. Your software doesn’t live alone. It has to talk to the payment provider, the shipping system, the spreadsheet downstream, and the report your leadership already trusts. Those conversations are where the actual engineering is.
Time. Six months from now, someone will need to change this thing. If the reasons behind its decisions were never written down, that person — possibly you — will be reverse-engineering your own software from its behavior. That’s the most expensive way to remember anything.
What to do about it
You don’t avoid these by demanding more screenshots. You avoid them by deciding, before building, what must be true for the software to be relied on — how many users, which systems, what happens when each one fails — and then building to that list instead of to the demo.
Then put it in front of real users early, with real stakes, and watch what breaks. Small breakage on a Tuesday is cheap. The same breakage after you’ve moved the whole operation onto it is not.
And write down the why. Every decision, one line, in one place. The demo impresses the room. The notes are what save you a year later.
AI shortened the distance from idea to demo to almost nothing. It didn’t shorten the distance from demo to product at all. That distance is where the work is — and it’s exactly the part nobody demos.
Working on something this applies to? Tell us about it — thirty minutes, no pitch.