Your AI-built prototype is not 90% done

A founder builds a prototype over a weekend with Lovable, Bolt or Cursor. It signs users in, saves records, sends emails. The demo lands, investors nod, and a reasonable conclusion follows: the product is nearly finished, and what remains is polish and a payment form.

That conclusion is wrong in a specific, predictable way. The prototype is the visible tenth of the product. The other nine tenths are the parts a demo cannot show, and they are most of the cost.

What the prototype actually proved

None of this makes the prototype worthless. It is probably the most useful artefact the business owns right now.

It proves demand cheaply. Put a working thing in front of ten prospective customers and you learn more in a week than three months of slide decks would tell you. It ends internal arguments: a clickable product settles debates that documents never do. And it makes iteration nearly free. Rearranging a whole workflow costs an afternoon, not a sprint.

Most usefully, it is a precise specification. A prototype that behaves the way the founder wants is a better brief than anything written in prose, produced at a price no agency could match. Treat it as that: the best brief you have ever commissioned.

What it does not prove is that the software can be trusted with strangers, their money or their data.

The work a demo cannot show

Walk through what production software carries that a demo never exercises.

Authentication, done properly, is more than a login form. It is password reset flows that cannot be abused, session expiry, token rotation and account lockout. Authorisation is a separate job again: deciding whether user A may read user B's invoices, enforced on every route and every database query. Hiding a button in the navigation is not authorisation. Prototypes almost always stop at the button.

Error handling is where demos flatter most, because demos only run the happy path. In production the Stripe webhook arrives twice, the file upload dies at 90%, the third-party API times out mid-request. Each failure needs a decision: retry it, queue it, alert someone, and tell the user something true. Nobody made those decisions in the prototype. The model guessed, or skipped them.

The data model is whatever the AI reached for first, which is fine until real customer data is in it. Then every schema change needs a migration that runs forward and rolls back without losing records. Observability means logs that can answer "what happened to this customer at 14:32 on Tuesday" and alerts that fire before the customer emails. A backup that has never been restored is a hope, not a backup. Rate limiting stops one script from filling your database or running up your AI API bill overnight. Accessibility (keyboard navigation, contrast, labelled forms) is basic decency and, for many public-facing services, a legal obligation.

Then there is the operational half: deployment someone other than the author can run, secrets kept out of the repository, a staging environment, dependency updates. Unglamorous, invisible in a demo, and the difference between software and a liability.

The flaws moved to where you cannot see them

The research on AI-generated code shows a pattern that should worry anyone judging a product by its demo.

Veracode's 2025 GenAI Code Security Report tested code from more than 100 large language models across Java, JavaScript, Python and C#, and found the generated code introduced security flaws in 45% of tests. Larger, newer models did no better.

Apiiro's analysis of several thousand enterprise developers between December 2024 and June 2025 found that AI-assisted developers shipped 3 to 4 times more commits, and the code looked cleaner: syntax errors down 76%, logic bugs down more than 60%. Meanwhile privilege escalation paths rose 322%, architectural design flaws rose 153%, and AI-assisted developers exposed cloud credentials nearly twice as often as their colleagues.

And in October 2025, Escape scanned over 5,600 publicly deployed vibe-coded apps built on platforms like Lovable and Bolt. They found more than 2,000 vulnerabilities, over 400 exposed secrets and 175 instances of exposed personal data, including medical records. Supabase service keys were sitting in frontend bundles, retrievable by anyone who opened the browser's developer tools.

Read those together and the shape is clear. The visible defects (syntax, obvious logic) are disappearing, which is exactly why the demo feels finished. The defects that grew are architectural: who can access what, where the secrets live, what happens under abuse. A demo cannot surface any of them. Only reading the code can.

When shipping the prototype as-is is fine

Sometimes the honest answer is: ship it. An internal dashboard for five colleagues who know it is a prototype. A calculator on a marketing page. An events signup that also writes to a spreadsheet, where the worst failure is a duplicate row. If it holds nobody else's personal data, takes no payments and has a small, known set of users, hardening it first is wasted money. Spend that money learning whether anyone wants the product.

The calculus flips the moment strangers arrive. Public signup, card payments, or other people's personal data each bring obligations (UK GDPR among them) and each turn a quirk into an incident. Our default: ship the prototype to people who know it is a prototype. Do not ship it to strangers who are trusting it with their data.

What production-ready concretely means

Production-ready is a checklist, not a feeling. A product is ready when:

• someone other than its author can deploy it, and roll it back
• a restore from backup has actually been performed, not assumed
• every route checks who is asking, and every query filters by ownership
• payments, uploads and integrations have defined behaviour when they fail
• logs can reconstruct what one user did on one day
• secrets live in a secrets manager, not the repository or the frontend bundle
• rate limits and cost ceilings exist, with numbers someone chose on purpose

Getting from a working prototype to that list usually costs as much as the prototype did again, and often more. Weeks, not days. Anyone who quotes you two days of polish has not read the code.

Salvage, refactor or rebuild

The way to decide is an audit, not instinct. Read the code. Trace where the data goes. Inspect the auth model and the deployment. It usually takes a few days and it beats months of guessing.

Three outcomes are common. Keep the frontend and rebuild the backend around a proper data model, which is the frequent case. Keep the lot and harden it, which is rarer but real, especially for narrow internal tools. Or treat the entire prototype as product discovery and rebuild, which is the right call when the data model itself is wrong, because a bad schema taxes every feature built on top of it.

The one move that reliably goes badly is skipping the decision: bolting new features onto an unaudited base while real customers pile in. That is how a weekend of impressive progress becomes a quarter of firefighting. Decide what the prototype is first. Then build the product.