AI tools build what shows in a demo: the screens and the main flow. They do not build what only shows up with real users: access rights, error handling, behaviour under load, and code someone can maintain.
That is why an app that worked flawlessly for three test users fails for three hundred real ones.
This is not a reason to avoid AI tools. It is a reason not to mistake a prototype for a product. This article covers the five places where AI-built prototypes most often break, and five questions you can use to check where you stand.
What "vibe coding" is and why the prototype works
"Vibe coding" is a term that took hold in 2025. It means you describe what you want, AI writes the code, and you do not read it. You only check whether the screen does what you expected. With tools like Lovable, Bolt, Replit or Cursor, an app that looks finished appears within days.
The prototype works for two reasons.
First, AI builds what you check. If you check the look and the main flow, the look and the main flow will be good. What you do not check stays open.
Second, you are the one testing it. You know where to click, what to type and what not to do. Real users do not. They enter a name with an apostrophe, double-click the pay button and open the app in three tabs at once.
A prototype proves that the idea works. It does not prove that the app works.
Five places where an AI prototype breaks
1. Several users at once
The prototype is built for one user at a time, because one user tested it. When two people edit the same record at once, one of them loses their changes. When a hundred open the same page, every query reads every row in the database, because with ten test rows nobody noticed.
The result is an app that gets slower with every new user until it stops.
2. Who may see which data
This is the most common and the most expensive mistake. Login works and every user sees their own screen, so the data looks separated. Often it is separated only on the screen. Anyone who can change a number in the address bar or send a request straight to the database sees everyone's data.
How this ends in practice is covered in Is AI-written code secure?.
3. Input you did not expect
AI writes code for the case you described. You did not describe an empty field, a 400-megabyte file, a date in the future or a connection that drops in the middle of a payment, so there is no code for them. In those cases the app shows a blank screen or, worse, saves the wrong data and carries on.
4. Costs that grow with use
For a prototype, hosting and the AI model cost a few euros a month. Nobody has worked out what one active user costs. If the app sends the whole conversation to the AI model on every click, or reads the whole database every time a page opens, the cost does not grow in line with users. It grows faster.
Companies usually notice with the first invoice after a successful launch.
5. Code nobody understands
As long as you keep building with the same tool, this is not a problem. It becomes one when something needs fixing that the tool cannot fix, or when a developer has to take the code over. They find the same logic in five places, no tests, and no explanation of why anything is done the way it is.
Every fix then takes longer than the last, and every change breaks something elsewhere.
When it goes wrong in production: a deleted database
In July 2025 Jason Lemkin, founder of the SaaStr community, spent twelve days publicly building an app with Replit's AI agent. On day nine the agent deleted the production database, even though a code freeze was explicitly in place. Replit's CEO apologised publicly and called it unacceptable. The data was later restored. Fortune reported on the case.
The lesson is not that the tool is bad. The lesson is that the prototype lacked what every serious product has: separate environments for development and for real data, limited permissions, and backups that have been tested. Nobody misses these in a prototype. In a product with customers, they are the difference between a bad day and the end of the company.
Five questions to check where you stand
Answer them yourself, without help from the tool that built the app.
What happens if a hundred people log in at once? Not "it will probably work", but: have you ever tried it?
Can user A see user B's data? Create two accounts and try the other one's address or record number.
Where are the backups, and have you ever restored one? A backup you have never restored is only a hope.
What does one active user cost you per month? Add up hosting, the database and the AI model.
Could a developer who has never seen the code fix a bug in a day? If you do not know, the answer is no.
If you cannot answer two or more of these, the app is not ready for real users.
Fix it or start again?
Usually fix it. Throwing the prototype away also throws away the most valuable thing in it: knowing what users actually need, and the screens they have already seen.
The user interface, the flow and the business rules usually stay. What tends to be rebuilt is the part you cannot see: the data structure, access rights and connections to other systems. Which parts fall where cannot be guessed from the outside. Someone has to read the code.
That decision is what our AI project rescue review is for. In two weeks we review the code, security and user experience, and tell you for each part whether to keep it, fix it or rewrite it, with a cost and a timeline for each option. See the AI Project Rescue package for what it covers and what it costs.
Frequently asked questions
Was it a mistake to build the prototype with AI?
No. A prototype built with an AI tool is today the fastest way to test an idea, and often the cheapest. It only becomes a mistake when the prototype turns into a product that customers trust with their data, without a review.
Can we fix the problems with the same AI tool?
Partly. AI is good at fixing a bug you point out. It does not find the bugs you do not know you have, and those are exactly the ones in this article. That is why a review has to come before the fixing, to say what needs fixing at all.
How long does it take to turn a prototype into a product?
It depends on how much has to be replaced. If the data structure is sound, it is a matter of weeks. If it has to be rebuilt, months. That is why it pays to find out first which of the two groups you are in.
We write about it. We also build it.
Let's talk about your project
A 30-minute call to understand what you're building and whether we're the right fit. Come as you are - no brief required.
Prefer email?
[email protected]