Vibe coding is magic in the demo. Is your app really production-ready?

On February 2, 2025, Andrej Karpathy named the thing: “There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Nine months later, “vibe coding” was Collins Dictionary's Word of the Year. Few tech terms have traveled that fast — because few tech experiences are that intoxicating.

The numbers say the same. Lovable reached $100M in annual recurring revenue eight months after launch, with more than 10 million projects created on the platform. Bolt.new reached roughly $40M ARR in about five months. Replit multiplied its revenue tenfold in half a year after launching its agent. Millions of people typed a sentence and watched software appear.

We understand the high. It's the same one our users feel when they describe a feature and see it running in their app. Seeing your idea work — not mocked up, working — changes what you believe you can build. That part deserves no irony.

But Karpathy put the caveat in the very same post: vibe coding is “not too bad for throwaway weekend projects.” The people living it say it with less restraint. One builder on r/nocode titled his post “Tried Bolt.new. Felt Like a God. Then Reality Slapped Me.” and summed up the morning after: “Suddenly, the dream of 'AI-powered coding' turned into 'AI-powered anxiety.'”

The demo isn't a lie. The mistake is reading it as a finished product.

Is vibe coding production-ready? For prototypes and internal tools, yes — brilliantly. For an app published in the stores, with real users and real data, not on its own. The real limitations of vibe coding are not in the code it writes; they are in everything production requires around that code.

The no-code industry itself has started naming the divide. Caspio's State of No-Code 2026 describes AI pulling the market in two directions at once and lands on a blunt formula: “The split is not 'AI good vs. AI bad.' It is disposable vs. durable.”

So what makes a vibe-coded prototype disposable? Not the demo — everything around it. Seven walls, each one invisible on a laptop screen, each one real the day you try to ship. Three of them — native code, store submission, and the app lifecycle — are so specific to mobile that we dedicated a full deep dive to them; here they take their place in the full picture.

Wall 1 — Hosting and ownership

To be fair to the tools: you generally own your code. Lovable's documentation says so explicitly, and you can export to GitHub. What you don't own is everything the code needs to run. By default your app lives on the vendor's managed cloud — Lovable Cloud, Bolt hosting, Vercel — with its backend, database, and build pipeline operated by them, on their pricing, under their terms. Owning the source of an app whose infrastructure belongs to someone else is like owning the blueprint of a house built on rented land. Production means someone answers for that infrastructure for years: uptime, backups, renewals, bills. In the demo, nobody does.

Mutualization. A SaaS platform runs one infrastructure for all its apps, operated by a team whose entire job is keeping it up — and the cost is priced into the subscription, not discovered later. Every app we've shipped has run on that model from day one.

Wall 2 — Backend and data

A prototype's data layer is optimized for the demo: it exists, it responds, it looks fine. Production data has harsher requirements — migrations, backups, environments that separate testing from reality. In July 2025, that lesson made headlines when Replit's agent deleted a production database during an explicit code freeze, wiping records on more than 1,200 executives. Replit responded by announcing automatic separation between development and production databases, closing a gap that production systems treat as table stakes.

And beyond the database, production is where unglamorous operational problems live. Transactional email is the classic: one SaaS founder reported on r/SaaS “often less than a 50% delivery rate” on shared email infrastructure. No prompt fixes deliverability.

A backend that predates your app. On a managed platform, the data layer — migrations, backups, the separation of testing from production — was engineered once, professionally, and is exercised daily by every app running on it; our e-commerce module alone runs in production for thousands of merchants. The unglamorous plumbing is a platform team's day job, not your week-three discovery.

Wall 3 — Authentication and security

This is the best-documented wall, because researchers keep measuring it. Veracode's 2025 study across 100+ models found AI-generated code introduced OWASP Top 10 vulnerabilities in 45% of tested tasks. An academic benchmark published in December 2025 measured the gap at its starkest: the best-performing agent produced functionally correct solutions 61% of the time, but only 10.5% of its solutions were secure. And in 2025 a CVE was filed documenting missing Row-Level Security in Lovable-generated apps — security researcher Matt Palmer scanned 1,645 of them and found 170 exposing data, including API keys and financial details. When Escape.tech scanned 5,600+ live vibe-coded apps in October 2025, it found 2,000+ vulnerabilities and 400+ exposed secrets.

None of this means the models are bad. It means security review is a production requirement that a prototype, by definition, has never been through.

Security written once, inherited by everyone. Platform authentication is a single codebase hardened by years of real traffic, and when something needs patching, the fix is written once — deployed server-side immediately, carried into every app's next build. That is the structural difference between one login maintained by engineers and thousands of generated logins, each reinventing its own access rules alone.

Wall 4 — Store submission

Here is the fact most vibe-coding tutorials skip: most prompt-to-app tools build web apps, not mobile apps. Lovable's own FAQ says it plainly: “No, Lovable is focused on web applications.” v0 generates web code deployed on Vercel. Bolt is the partial exception — its Expo integration generates real React Native code — but the binary builds, the developer accounts, and Apple's review remain entirely your problem.

The commonly suggested workaround — wrap the web app in a native shell — runs into Apple's Guideline 4.2: “Your app should include features, content, and UI that elevate it beyond a repackaged website.” In our publishing team's experience, reviewers routinely test apps offline; a wrapper that shows a blank screen tells them everything. And review is unforgiving even for real apps: Apple rejects roughly 42% of first submissions (Apple's baseline, measured across apps our publishing team submitted over the last 12 months). We wrote a guide to why Apple rejects apps and how to recover.

Submission as an industrial process. A platform compiles binaries designed to pass review, and when Apple or Google moves the bar — new privacy labels, new SDK deadlines, new completeness checks — it updates once and every app it ships inherits the fix. Fifteen years of store submissions is a form of capital no prompt can generate.

Wall 5 — Native device features

The features that make a mobile app worth having over a website are precisely the ones a wrapped web app struggles with. Push notifications are the sharpest example: on iOS, web push only works for web apps manually installed on the Home Screen — never in the browser. Camera, offline mode, biometrics: each requires native plugins to be added, configured, and maintained by hand, outside anything the AI generated. A “mobile-friendly” web demo and a native app are different species wearing the same interface.

Native by construction. On a platform that compiles real Swift and Kotlin, push, camera, offline, and haptics are pre-built components maintained through every iOS and Android release — the layer that makes an app feel professional is the baseline, not an afterthought.

Wall 6 — Regeneration drift: the code that rewrites itself

Call it regeneration drift: each new prompt regenerates code against a slightly different context, and yesterday's fix can quietly disappear into today's generation. Addy Osmani, engineering lead on Google Chrome, named the pattern “two steps back”: “You try to fix a small bug… The AI suggests a change that seems reasonable… This fix breaks something else.” The data agrees: GitClear's analysis of 211 million changed lines of code found blocks of five or more duplicated lines up 8x in 2024, and the share of code revised within two weeks of being written nearly doubled since 2020. A codebase that won't hold still is a codebase you can't promise anything about — least of all to a user who found a bug.

A foundation that holds still. On a platform, AI generates only the thin custom layer on top of a versioned, tested substrate — authentication, checkout, CMS, design system are part of the substrate no prompt ever regenerates. Drift is confined to the thin custom layer instead of your whole app: the checkout you rely on can't quietly rewrite itself.

Wall 7 — Privacy and compliance

A shipped app carries legal obligations a demo never meets. Apple's privacy labels and Google Play's Data safety form both require you to declare what data you collect, where it goes, and who processes it — questions a vibe-coded stack often can't answer, because a default somewhere placed your users' data on infrastructure you never chose. GDPR raises the bar further: consent that is specific and unbundled, data residency you can actually state, a list of processors you actually know. None of it shows up in a demo. All of it shows up in a store review, or worse, in a complaint.

Compliance handled once, upstream. One platform-level legal and engineering effort — in our case, all data hosted in Europe, built-in consent management, automatic detection of the permissions each feature requires — serves every app, and stays current as the rules evolve. Our compilation engines go one step further: a library only ships in the binary if the feature using it is activated, so apps don't just declare less, they contain less.

The seven walls of vibe coding — summary

Seven walls, seven questions. The platform answers above are ours; these questions are yours. Answer them about your prototype:

1. Who operates the infrastructure it runs on — and will they still, in two years?
2. Where does the data live, and what happens when the schema has to change?
3. Has anyone who can read code reviewed the authentication and access rules?
4. Can it produce a signed iOS and Android binary that passes store review?
5. Can it send a push notification to a locked phone?
6. Can you fix one bug in six months without regenerating — and re-breaking — the rest?
7. Would the consent flow and data handling survive a GDPR complaint?

Three or more “no” (or “I don't know”) answers, and what you have is a prototype. That is not a failure — a prototype is a genuinely useful thing. It validates an idea in an afternoon for almost nothing. The failure is only in the confusion: planning a launch, a user base, and a business on something built to be disposable.

The conclusion is not “avoid AI.” We use AI code generation daily in our own engineering teams — our CMO said as much back in April 2025, along with the caveat the industry has since confirmed: “Without programming knowledge, you can quickly find yourself overwhelmed or blocked, as AI can create significant inconsistencies if used without expert human supervision.”

The conclusion is to point AI speed at a foundation that ships. That is the entire logic of the AI Extension Builder (currently in Beta, available to all customers), GoodBarber's answer to the prompt-to-app question: you describe a feature in plain language, an AI agent builds it — but it builds inside a platform, against documented APIs, so the result inherits everything a prototype lacks. The design follows your app's design system automatically. The section ships as genuine Swift and Kotlin binaries, through the same store pipeline we've operated since 2011 — with a publishing team that recovers 91% of Apple first-submission rejections when they happen (last 12 months).

Walls 2 and 3 — backend and security — get the same treatment. When an AI-built section needs to store data, the Supabase integration creates the database structure for you, in your own Supabase project, on infrastructure you control — and every table ships with Row-Level Security policies by default. That is the exact failure mode documented in the Lovable CVE, handled before you knew to ask about it. And the platform core — hosting, database, push notifications, analytics, and payments — is included in one subscription, so there is no stack of third-party services to assemble, secure, and pay for separately. Total cost of ownership: around one-tenth of custom development.

There are limits, of course. GoodBarber is built for content apps and mobile commerce; a game or a heavily custom marketplace falls outside that scope, and for those projects a vibe-coded prototype handed to a development team is a more natural path. Within that scope, though, the platform approach is what turns AI speed into an app you can ship — and keep running over time.

The next step, concretely: start a free trial, open a “Create with AI” section, and describe the feature you vibe-coded last weekend. Same five minutes. This time, the result has a store pipeline behind it.

Can you publish a vibe-coded app to the App Store?

Not directly, in most cases. Lovable and v0 produce web applications — there is no iOS or Android binary to submit. Wrapping the web app in a native shell is possible, but Apple's Guideline 4.2 rejects apps that amount to “a repackaged website.” Bolt can generate React Native code via Expo, but the builds, developer accounts, and store review remain on you. The reliable paths are: hire developers to productionize the code, or rebuild on a platform that compiles native binaries and handles submission. For the full mobile-specific analysis, see what vibe coding tools forget to tell you about mobile apps.

Is vibe coding production-ready?

For prototypes, internal tools, and weekend projects — yes, and it's excellent at them. For production apps with real users, the measured answer is: not without engineering review. AI-generated code introduces security vulnerabilities in 45% of tested tasks (Veracode, 2025), and an academic benchmark found its best-performing agent's solutions functionally correct 61% of the time but secure only 10.5% of the time (arXiv, December 2025). Production-readiness isn't about whether the code runs — it's about hosting, data, security review, store submission, native features, code stability, and compliance: the seven walls of vibe coding.

What is regeneration drift in vibe coding?

Regeneration drift is what happens when each new AI prompt regenerates code against a slightly different context, so yesterday's fix can quietly disappear into today's generation. Addy Osmani calls the resulting loop the “two steps back” pattern; GitClear's analysis of 211 million changed lines measured its footprint — duplicated code blocks up 8x in 2024. It is the main reason a vibe-coded app gets harder to maintain the longer you keep prompting it.

Did Apple ban vibe-coded apps?

No — and the distinction matters. In March 2026, Apple blocked updates to vibe-coding platform apps like Replit and Vibecode under Guideline 2.5.2, which forbids apps that download and execute code. That targets the tools as iOS apps, not apps built with AI. Apple told MacRumors it has no rules specifically against vibe-coding apps. An individual AI-built app faces the ordinary bar instead: minimum functionality (4.2), spam (4.3), and completeness — the same review every app faces.

When should you move from a vibe-coded prototype to an app builder?

The moment the prototype has to become someone's daily tool: real users, a store presence, updates, a backend that persists. That is a responsibility threshold, not a skill threshold — the day other people depend on the app, someone has to answer for its seven walls. Keep the prototype; it did its job validating the idea. Then rebuild it where those walls are already someone else's job — native binaries, store submission, hosting, and maintenance included. As our CMO put it, vibe coding serves an expert audience; an app builder is built for everyone else.

What does publishing to the stores actually cost?

An Apple Developer account is $99/year; a Google Play developer account is a one-time $25. Then comes the real cost: preparing builds, screenshots, privacy declarations, and surviving review — Apple rejects roughly 42% of first submissions (Apple's baseline, measured across apps our publishing team submitted over the last 12 months). Our step-by-step publishing guide covers the process, and our publishing service does it for you.