Production-ready vs demo-good: the vibe-coding reality check

"Demo-good" means the app works when you run through it. "Production-ready" means it keeps working — correctly and safely — when strangers use it in ways you did not anticipate. The gap between the two is not a failure of vibe coding as a concept. It is a checklist of specific capabilities that AI app builders do not add automatically: tested authentication, enforced data isolation, observable failures, backups you have verified, and a path back to "working" when something goes wrong. How much of that checklist you need depends on what the app does and who uses it.

Why this distinction matters

A remarkable number of founders have shipped a vibe-coded app, watched it work perfectly in their own testing, and then discovered a problem only after a real user encountered it. The most common version of that story: something that was fine in a single-user demo breaks under multi-user conditions — one user's data appears in another user's session, a payment webhook fails silently, or a backend job that worked in testing runs into a real-world edge case with no error visible anywhere.

The other version: the app works correctly for every user who uses it the intended way, but does not survive deliberate misuse — an automated script that hits the API a thousand times, a user who changes the ID in a URL and gets someone else's data, or a token that was hardcoded in a commit six weeks ago and has been sitting in a public GitHub repo ever since.

None of this means vibe coding is the wrong choice. It means that "it works in my demo" is not the same bar as "it is ready for people I do not personally know." This article defines that second bar, and tells you how much of it you need based on what you are actually building.

The eight dimensions of production readiness

These are the capabilities that separate a demo from a production deployment. Each one is a gap that AI builders do not fill automatically — and each one has a clear, plain-English definition.

1. Authentication: who can reach it

Demo bar: there is a login screen and it works.

Production bar: authentication is enforced server-side, not just in the UI. An unauthenticated request to a data endpoint returns nothing. Session tokens expire and can be revoked. Password reset flows work and only affect the correct account. There is a clear policy for what happens when a user account needs to be suspended.

What goes wrong without it: users who know the URL of an API endpoint can bypass the login screen entirely and access data directly. This is the pattern behind the RedAccess finding of more than 5,000 exposed vibe-coded apps, approximately 40 percent of which exposed sensitive data.

2. Data access: who can see what

Demo bar: users can see their own data.

Production bar: users cannot see each other's data. One user cannot access another user's records by changing an ID in a URL, a network request parameter, or a JSON body field. This check is enforced at the database layer or the API layer — not just in the frontend UI. If the app has roles (admin, premium, standard), those roles are verified server-side on every request that uses them.

What goes wrong without it: this is Broken Object Level Authorization — OWASP's top-ranked API vulnerability. It is also the most common authorization failure in AI-generated code, precisely because the AI generates logic that returns the right data for the happy path without adding the check that prevents returning the wrong data under variation.

3. Testing: what you know it survives

Demo bar: you ran through the main flow and it worked.

Production bar: the critical paths have been tested by someone other than the builder. Multi-user scenarios have been tested with at least two separate accounts. Edge cases — empty states, large inputs, concurrent actions, failed payments, expired sessions — have been attempted. There is at least an informal list of what was tested and what was not.

What goes wrong without it: the SusVibes benchmark found that the best-performing AI agent/model combination had a 61 percent functional pass rate but only a 10.5 percent secure pass rate. That gap is not random — it correlates directly with the kinds of tests that are easy to write (does it return the right answer?) versus the kinds of tests that are hard to remember to write (does it return someone else's answer when it should not?).

4. Secrets and credentials: where the keys live

Demo bar: the app connects to its services and they work.

Production bar: every API key, database credential, and service token is stored in a server-side secret management system — not hardcoded in source code, not embedded in a frontend file, not in a repository where it could be read. A developer or auditor can verify the secret storage without having to look at the running app. Spend limits are set on every paid service.

What goes wrong without it: a single exposed Stripe key led to 175 customers being charged $500 each and $2,500 in Stripe fees in one publicly documented incident. The key had been in the app's code. Veracode's testing of more than 100 AI models found that 45 percent of AI-generated code samples introduced OWASP Top 10 vulnerabilities.

5. Observability: knowing when something goes wrong

Demo bar: you can tell from the UI whether an action worked.

Production bar: errors are logged somewhere you can see them — not just in a browser console that only you can open. Unexpected failures surface as alerts, not as silent no-ops. Payment failures, authentication errors, and data-write failures leave a record. You know within hours (ideally minutes) if something breaks for a user, rather than finding out when a user emails to say something is wrong.

What goes wrong without it: silent failures are the worst kind. A payment webhook that fails silently means you never know a payment did not process. An authentication error that fails silently means a user cannot log in and has no way to tell you why. At scale, silent failures compound; one failing system creates load on another until the whole thing degrades in a way that is very difficult to diagnose after the fact.

6. Backups: what you do when data is lost

Demo bar: the data is in the database.

Production bar: the database is backed up on a schedule you know, and you have verified that the backup can actually be restored. "My cloud provider backs up automatically" is not sufficient unless you have tested the restore process. You know what the maximum acceptable data loss is (one hour? one day?) and your backup schedule is compatible with that number.

What goes wrong without it: data loss at the application layer — a bug that overwrites records, a deploy that drops a table, a user who deletes something they should not — is a different failure mode from infrastructure failure. Cloud provider backups protect against infrastructure failure. Application-layer errors require point-in-time restore or an application-level export mechanism. Most vibe-coded apps have neither.

7. Rollback: getting back to working

Demo bar: when you push an update, the new version runs.

Production bar: when an update breaks something, there is a defined path back to the last working version. You know which version is running, you know how to deploy the previous version, and you have done it at least once in a non-production context so you know it works. If the app uses a database schema, schema migrations have a reverse step.

What goes wrong without it: a broken deploy with no rollback path leaves you debugging a broken app in production, with real users affected, under time pressure. Every change to a production app is a risk; rollback is the safety net that makes it acceptable to take that risk.

8. Ownership and handoff: who maintains it

Demo bar: you built it and you know how it works.

Production bar: someone — you or someone else — has documented what the app does, what services it depends on, what credentials it uses, and what the process is for common operational tasks (adding a user, changing a setting, handling a billing dispute). If the person who built it were unavailable for two weeks, is there enough documentation for someone else to keep it running and handle a basic incident?

What goes wrong without it: vibe-coded apps are especially vulnerable here because the "documentation" is often entirely implicit — in the builder's head and in the AI chat history. Community threads on production readiness cite this explicitly: what breaks when real users, payments, roles, background jobs, and edge cases appear? The answer is: whatever was not documented and is not understood by anyone other than the original builder.

The risk-class matrix: how much of this do you actually need

The bar is not the same for every app. A personal productivity tool you use yourself has different requirements than an app that handles paying customers' financial data. Use this matrix to locate your app.

The four most common gaps in AI-built apps, by stage

This is what the research actually shows breaks:

Stage 1 (demo to first external user): visibility configuration and secrets. The app is publicly reachable when the builder assumed it was private, or API keys are visible in the browser. Both are pre-launch checks. The pre-launch security checklist covers both in detail.

Stage 2 (first users to multiple users): data isolation. The first user never notices that other users can see their data, because they are the only user. The failure appears the moment there are two accounts. This is the Broken Object Level Authorization failure, and it is the most common authorization vulnerability in AI-generated API code.

Stage 3 (multi-user to real payments or sensitive data): spend limits, rate limiting, and payment integration review. The specific risk: an exposed endpoint that costs money per call, with no limit on how many times it can be called. The Stripe key incident cited above is the cleanest example of how quickly this can go wrong.

Stage 4 (operational to scaling or change): observability, rollback, and documentation. These do not block launch — they prevent a bad week from becoming a catastrophe. An app that has no error logging, no rollback path, and no documentation is fragile in a specific way: it works until something changes, and then diagnosing and fixing it takes much longer than it should.

Tool-specific notes on production gaps

Lovable

Lovable is well suited for moving fast to a working prototype with auth and a database. The gap that most commonly bites Lovable users at the production stage: the generated data access logic does not enforce object-level authorization. Lovable may generate RLS policies that handle the user's own data correctly without handling what another user should be blocked from — particularly on edge cases like shared resources, admin views, or team memberships. Testing with two separate accounts is mandatory before launch.

Replit

Replit gives you real backend code, which means the production bar is achievable — and also means there is more code to review. The most common Replit production gap: error handling and logging. AI-generated backend code tends to handle the happy path and either silently ignores errors or crashes the request without leaving a record. Adding structured logging to the server-side code before launch makes the operational life of the app substantially easier.

Bolt and v0

Both tools generate frontend-only code. They are excellent for the prototype risk class and can work for internal tools where the frontend connects to a well-secured backend. They are not appropriate for the paid-beta or regulated risk class without a properly built and reviewed backend. The production bar for these tools is lower not because the app needs less — it is lower because the scope of what these tools produce is smaller. The backend you connect them to still needs to meet the full bar for its risk class.

Base44

Base44's platform manages a substantial portion of the auth and data model for you, which raises the starting point. The main production gap for Base44 apps is in the data permissions settings — which users can read or write which data objects — and in understanding what the platform's access controls do and do not cover. The Wiz-documented authentication bypass in 2026 was patched quickly, but it illustrates that platform-managed auth is a dependency on the platform's own security record, not a guarantee.

Cursor and Claude Code

These tools give you the most control and the most responsibility. The production bar for a Cursor or Claude Code app is the same as for any application — because you have a full codebase, a full deployment, and full ownership of what is in it. The specific production gap for AI-generated code in these tools: the functional and security pass rates diverge significantly. Veracode found that 45 percent of AI-generated samples introduced OWASP Top 10 vulnerabilities. The code needs review by someone who can read it, not just by someone who can run through the UI.

What to do with this information

This framework is most useful as a conversation starter, not a final verdict. The right question is not "is my app production-ready?" in the abstract — it is "for the risk class I am targeting, which dimensions am I confident about, which am I uncertain about, and which have I not looked at yet?"

Most founders who come to AgentC for a review are in the paid-beta or early-SaaS class with clear confidence on sections 1 and 3 (their app has login and they have tested the main flow) and uncertainty on sections 2, 4, and 5 (data isolation, secrets, and observability). That is a reasonable starting point. Those three dimensions are where the most consequential gaps tend to live.

If you want AgentC to walk through this framework with your specific app — locate it in the risk matrix, identify the gaps, and tell you plainly what is and is not ready — the right starting point is a demo conversation. We look at what you have built, ask the questions that matter for your situation, and give you a clear and specific assessment.

Related guides in this series

• Is your AI-built app safe to put in front of customers? (the pillar guide) — the full triage across all security areas
• The pre-launch security checklist for Lovable, Replit, Bolt, and Base44
• How to tell if your Supabase database is exposed (without being a developer)
• Which vibe-coding tool should you use? Choose by risk, not hype
• Can someone see another user's data in your AI-built app?

Frequently asked questions

Can a vibe-coded app ever be production-ready?

Yes. "Vibe-coded" describes how it was built, not what it is capable of being. The same dimensions that make any app production-ready apply: authentication enforced server-side, data isolated between users, secrets stored correctly, errors observable, backups verified, rollback defined, and someone accountable for maintenance. AI builders make those capabilities faster to reach — but not automatic. The question is whether they were actually configured, not whether the tool is capable of it.

What is the most common mistake that prevents vibe-coded apps from being production-ready?

Object-level data isolation — whether one user can access another user's records. This is the failure that appears in the transition from single-user testing to multi-user production. It is almost never visible in the demo stage because the demo has one user, who always sees exactly their own data. It becomes visible the moment a second account exists and someone tests whether they can see the first account's data by changing a URL or request parameter.

How long does it take to make a vibe-coded app production-ready?

It depends on the risk class and what the AI builder generated. For a prototype moving to an internal tool — assuming auth is in place and data isolation checks out — the gap might be a few days of adding logging, confirming backups, and documenting the operational basics. For an early SaaS moving to paying users with a Supabase backend, fixing data isolation issues, adding rate limits, confirming secrets, and getting a basic observability layer in place might take a week or two with a developer involved. For a regulated category, the timeline is longer and the scope is wider — expert review is a prerequisite, not an option.

Should I rebuild from scratch or fix what the AI built?

This depends on the size of the gap and the quality of the generated foundation. For most early-stage apps, fixing what was built is the right path — the value was getting to a working prototype quickly, and that work is not wasted. A rebuild makes sense when the data model is fundamentally wrong for the requirements, the codebase has become too tangled to reason about, or the risk class changed substantially after the initial build (for example, an internal tool that is now handling payments and regulated data). The question is whether the foundation can carry the weight of what you are trying to build on top of it.

Is "production-ready" binary?

No. Production readiness is a spectrum calibrated to the risk class. A personal productivity tool and a regulated healthcare app require very different things. The framework in this article is deliberately graduated: the prototype class has a much shorter checklist than the regulated class. What matters is that your actual app's configuration matches its actual risk class — not that it matches some universal standard that does not account for scope and use case.

Does getting a security audit mean the app is production-ready?

A security audit addresses specific dimensions — typically secrets, authentication, data isolation, and code-level vulnerabilities. It does not automatically verify observability, rollback, backup, or documentation. A useful audit should tell you which of the eight dimensions it covered, what it found, and what it did not cover. An audit combined with this framework gives you a more complete picture than either alone.

About this guide

Written by Seth Tucker, founder of AgentC Consulting. Seth spent approximately five years as a security engineer on election infrastructure used by roughly one in three American voters, holds SOC 2 Type 2 and ISO 27001 experience, and now helps non-technical founders and operators build, review, and trust AI-built applications.

Last updated: June 2026. Sources cited throughout reference original research, vendor documentation, and public reporting.