Vibe-coded prototype vs production build
A working demo built in a weekend is a real achievement. The gap between that and software your customers depend on is where most of the cost lives.
The short answer
Build a prototype to find out whether anyone wants the thing, and build for production once real people, real money or real data depend on it being right.
Prototypes are optimised for one thing: showing that an idea works on a good day. They skip the parts that only matter on a bad one. That is a reasonable trade while you are still learning whether to continue.
The mistake is treating the demo as nearly finished. It is usually the smallest part of the work, and the remaining share is invisible in a screen recording.
Side by side
What each one is actually for, and what it is allowed to ignore.
| Dimension | Prototype | Production build |
|---|---|---|
| Question it answers | Does anyone want this | Does this hold up under real use |
| Who uses it | You, a demo audience, friendly testers | Customers who have other options |
| When something fails | Reload and try again | It must recover, and someone is told |
| Access control | Often one shared login | Roles, per-user rules, an audit trail |
| Data | Sample data, reset when convenient | Real records, backed up, never lost |
| AI quality | It looked right in the cases we tried | Scored against known answers, watched over time |
| Change safety | Change anything, see what breaks | Tests, review and a way back |
| After launch | Nothing. It gets thrown away | Monitoring, patching, support, on call |
- It worksThe demo. Real, and the easy part
- IdentityWho is allowed to see what
- FailureRetries, limits, a safe stop
- EvidenceLogs and evals when output is wrong
- Someone on callThe part nobody demos
Only the first box is visible in a screen recording. The other four are what people are buying.
Vibe-coded prototype
Where it wins
- You learn whether the idea has legs in days rather than months, which is worth a great deal.
- A working demo persuades people in a way that a document never has.
- It exposes the hard question early, usually the one nobody had thought about.
- Throwing it away is cheap, and being willing to is what makes it useful.
Where it hurts
- Security is usually absent rather than weak, and a shared login is normal at this stage.
- It behaves well on the happy path and unpredictably everywhere else.
- AI output was judged by looking at it, so nobody knows how often it is wrong.
- It creates false confidence about timelines, because the visible part is done and the invisible part has not started.
Production build
Where it wins
- It survives real users doing things nobody predicted, which is the entire point.
- Access rules mean one customer cannot see another's data, which is not optional once you have two customers.
- When output is wrong you can find out why, because the system keeps evidence.
- Changes are safe to make, so the product can keep improving after launch instead of freezing.
Where it hurts
- It costs more and takes longer, and much of that work is invisible to whoever approved it.
- It needs people afterwards. Software with nobody maintaining it decays quietly.
- Building it before demand is proven is an expensive way to discover nobody wanted the thing.
- The discipline slows down experiments, so keep a space where prototypes are still allowed to be scrappy.
How to choose
- Choose a prototype if you cannot yet name the person who will pay for this and why.
- Choose a prototype to settle an internal argument. A rough version answers in a week what a debate cannot in a month.
- Choose a production build once anyone outside your company depends on it, especially where money or personal data is involved.
- Choose a production build the moment a second customer appears, because that is when one seeing another's data becomes possible.
- Choose to rebuild rather than harden when the prototype has no tests and nobody understands the code. Reading it can cost more than writing it again.
- Choose neither if the problem is a process nobody follows. Software will not enforce a rule the business has not agreed on.
Systems we took past the demo
Questions founders ask about the gap
01Can a vibe-coded prototype be hardened instead of rebuilt?
The data model decides it. Where the structure underneath is reasonable, you can add access rules, tests and error handling around it a piece at a time. Where the data model is wrong, hardening means patching the same flaw again and again. Get someone to read the code and say honestly which situation you are in.
02How much of the work is left after the demo works?
More than it looks, and the honest answer depends on what the software touches. Anything holding money, personal data or multiple customers carries a large amount of invisible work: permissions, validation, audit trails, failure handling and the tests covering them. Nobody can give you a ratio without seeing the code, and a vendor who quotes one has guessed.
03Our prototype already has users. Are we in production?
You are in production whether or not the software is ready, which is the uncomfortable version. Once outsiders depend on it, an outage is their problem too. Treat that as a deadline rather than a milestone: add access control, backups and monitoring first, since those are the failures that cannot be undone.
04Does AI-assisted coding change the answer?
It changes the speed of the first version, not the requirements of the last one. Generated code still needs review, tests and someone who understands it well enough to fix it at midnight. The demo arriving faster is genuine progress. The work after it has not shrunk in the same proportion.
05What should we insist on before calling something production-ready?
Four things, at minimum. Real access control, backups you have restored at least once, monitoring that tells a person when something breaks, and a scored set of examples for any AI output. Restoring a backup matters more than having one. An untested backup is a hope rather than a plan.
