Vibe-Coded App to Production: What Breaks and How to Fix It
AI builders get you to a working demo fast; real users and real payments test what they skip. What fails first, what to fix in place, when to rebuild and what to check before launch.

Key takeaways
- In Veracode's 2025 test of 80 coding tasks across more than 100 AI models, generated code introduced a security flaw in 45% of cases; its fall 2026 snapshot of 18 models still found about 38%.
- In a 2025 scan of 1,645 Lovable projects, researcher Matt Palmer found 170, about 10%, that let anyone read or write their data because of missing or weak Row Level Security; the flaw became CVE-2025-48757.
- Vite and Next.js put every VITE_ and NEXT_PUBLIC_ variable into the code the browser downloads, and a Supabase secret key bypasses every Row Level Security policy; Supabase is retiring its legacy anon and service_role keys by the end of 2026.
- Stripe's docs warn that webhook events can arrive more than once and out of order, and that unverified events let an attacker fake paid orders: verify the signature, log event IDs and check the amount.
- Supabase's Free plan includes no backups and Pro keeps 7 days of daily backups without Storage files; in April 2026 a coding agent deleted PocketOS's database and its same-volume backups in 9 seconds, The Register reported.
A vibe-coded app is safe to launch once someone has checked four things AI builders leave to you: who can read the database, which keys ship to the browser, how payments are confirmed and whether you can restore yesterday's data. In Veracode's 2025 test of more than 100 AI models, generated code introduced a security flaw in 45% of cases, and its fall 2026 snapshot of 18 models still put the rate at about 38%. Most of what breaks first can be fixed in place, without a rewrite.
This guide is for founders who built an app with Lovable, Bolt, Replit, v0, Cursor or Claude Code and now have real users or a first payment coming. Inside: what breaks first, incidents on record, a fix-or-rebuild table, what a cleanup involves and costs, US and UAE privacy rules, and a checklist.
Is a vibe-coded app safe to launch?
Vibe coding means building software by describing it to an AI tool and accepting its code mostly unread. The tools handle what you can see: screens, forms, sign-up. They skip what stays invisible until real users arrive: who may read which data, where keys live, what happens when a payment notice arrives twice, backups and alerts.
Lovable scans database rules, dependencies and exposed MCP servers when you publish, yet its security docs say the scans "cannot guarantee complete security" and "you are responsible for ensuring that your app meets the security requirements appropriate for its use case."
A demo for ten friends is fine. An app that stores personal data or takes money needs a review first. Most incidents below come from broken access control, number one in the OWASP Top 10:2025 list of web application risks.
What breaks first when a vibe-coded app goes to production?
Incidents and research point to the same list, roughly in order of harm.
Database access rules
In many AI-built apps the browser talks to a hosted database directly. Lovable's FAQ says its older apps "use React + Vite and render in the browser", backed by its built-in backend or your own Supabase project. Then the only thing between a stranger and your users' data is Row Level Security (RLS): database rules that decide which rows each user may read or change.
Supabase's RLS guide is blunt: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." Its Security Advisor flags such a table as an error: "Anyone with your project URL can read, edit, and delete all data in this table."
Switching RLS on is half the fix: with no policies, the API returns no data and the app stops until someone writes the rules. And a policy that exists is not a policy that works. Researcher Matt Palmer, who reported the Lovable flaw, noted that the scan Lovable shipped in April 2025 "merely checks for the existence of any RLS policy". A rule like "any signed-in user may read every row" passes that check and still leaks everything.
Secret keys in the browser
Anything the browser receives, anyone can read. Vite says variables prefixed with VITE_ "will be exposed in client-side source code" and should not hold API keys. Next.js inlines NEXT_PUBLIC_ values "into the js bundle that is delivered to the client".
Supabase's publishable key may sit in the browser because RLS limits what it can reach. The secret key "bypasses every Row Level Security policy you have", and the API key docs say never to put one "in a browser, a shipped application, or source control." Supabase is deprecating the legacy anon and service_role keys by the end of 2026. The same goes for AI keys: one in front-end code lets any visitor spend your balance.
Payments that trust the wrong signal
The usual setup is Stripe Checkout plus a webhook, a call from Stripe to your server saying the payment went through. Stripe's webhook docs list what the handler must survive:
- Fake events. "Without verification, an attacker could send fake webhook events to your endpoint to trigger actions like fulfilling orders". Check the
Stripe-Signatureheader against the raw request body. - Duplicates. Endpoints "might occasionally receive the same event more than once", so log processed event IDs.
- Order. Stripe "doesn't guarantee the delivery of events in the order that they're generated."
- Retries. In live mode, Stripe retries for up to three days, so a broken handler can fail quietly for days.
The database matters as much. If the paid flag sits in a row the browser can write, a user can mark themselves as paid. In Palmer's 2025 tests, an unauthorized write set "payment_status": "paid" on a live Lovable-built site.
Backups, environments and agent access
Supabase's backup docs give Pro projects 7 days of daily backups, Team 14 and Enterprise up to 30. Free projects get none, and point-in-time recovery is a paid add-on. "Database backups do not include objects you store via the Storage API", so uploads need their own copy.
Coding agents need limits too. In July 2025, during a "code and action freeze", Replit's agent deleted a live database with data on more than 1,200 executives and over 1,190 companies, Fortune reported. Replit now separates development and production databases, and its docs say: "Agent is not able to modify the production database."
In April 2026, a Cursor agent working on PocketOS found an API token in an unrelated file and, with one call to the host Railway, deleted the production database and its backups in 9 seconds, The Register reported. The token was made for custom domains but could do anything, and, the founder said, Railway "stores volume-level backups in the same volume". Railway's CEO helped restore the data within an hour.
The lessons: keep agents off production, give each token only the rights it needs, keep one backup outside the app's own account and test a restore.
Errors nobody sees
A generated app rarely comes with error reports or downtime alerts. When the payment handler fails, the customer sees a spinner and nobody on your side knows. The OWASP Top 10:2025 lists both halves: Security Logging and Alerting Failures (A09) and Mishandling of Exceptional Conditions (A10).
AI features that bill per request
If the app calls an AI model, every request costs money. OWASP's LLM10:2025 Unbounded Consumption calls the abuse Denial of Wallet: attackers exploit cost-per-use pricing, "leading to unsustainable financial burdens on the provider". Its advice: apply "rate limiting and user quotas". Our guide to AI agent costs covers normal running costs.
App Store and Google Play
Apple's App Review Guidelines want more than "a repackaged website" (4.2), reject binaries "that crash or exhibit obvious technical problems" (2.1) and require in-app account deletion when the app lets people create an account (5.1.1(v)). On Google Play, personal developer accounts created after November 13, 2023 need "a minimum of 12 testers who have been opted in continuously for at least 14 days" before production. If the store version needs a new build, see our comparison of Swift, Flutter and React Native.
Vibe coding security risks: what has already happened
Public incidents with apps built by AI tools or run by coding agents. Primary reports and records, checked November 1, 2026.
| When | What happened | Root cause | Source |
|---|---|---|---|
| Mar–May 2025 | 170 of 1,645 scanned Lovable projects let anyone read or write their data; logged as CVE-2025-48757, rated 9.3 Critical | Missing or weak RLS | NVD record, Palmer |
| Jul 2025 | Replit's agent deleted a live database during a code freeze | The agent could write to production | Fortune |
| Oct 2025 | Scan of 5,600+ public vibe-coded apps: 2,000+ vulnerabilities, 400+ exposed secrets, 175 cases of exposed personal data | Exposed Supabase tokens, missing RLS, misconfigured APIs | Escape |
| Jan–Feb 2026 | Moltbook: 1.5 million API tokens, about 35,000 emails and 4,060 private conversations open to read and write | Supabase key in the JavaScript bundle, no RLS | Wiz |
| Apr 2026 | PocketOS lost its production database and backups in 9 seconds | A token that could do anything; backups on the same volume | The Register |
Three notes on fairness. Lovable disputes the CVE: the record states its position that each customer is responsible for its app's data. Escape ran passive scans only, so its numbers are a lower bound. Moltbook's founder had posted that he "didn't write a single line of code" for the site; Wiz found a public key with no RLS behind it, which "grants full database access to anyone who has it."
What the research says
In 2025, Veracode gave 80 coding tasks to more than 100 large language models: 45% of cases introduced vulnerabilities, Java failed more than 70% of the time, and models failed to block cross-site scripting in 86% of relevant cases and log injection in 88%.
The fall 2026 update, published October 29, 2026, tested 18 models on code written "when given no security-specific guidance". The average security pass rate rose from 56% in July 2026 to 62%, "the first meaningful movement in the series". Nearly all of it passed the syntax check. Cross-site scripting was the biggest single driver of the gain; log injection and Java barely moved.
Our reading: code that runs and looks right still fails a security check almost 4 times in 10. Review closes that gap; newer models have not closed it yet.
Should you fix or rewrite a vibe-coded app?
Most apps need a fix, not a rewrite. Access rules, leaked keys and payment handling can be repaired in the existing code. A full rebuild is justified when the data model is broken at the root, or when the app sits on a platform it cannot leave.
Check the platform first. Lovable says "you own what you create" and lets you host "wherever you choose". Git sync works on every plan; the ZIP download needs a paid plan. The export carries the database schema but not the data or uploaded files, and moving only PostgreSQL "does not move authentication, storage, realtime, or Edge Functions." Plan those as a separate move.
Fix in place or rebuild: the signals we weigh in a review. Our rules of thumb, checked against Lovable's and Supabase's docs on November 1, 2026.
| Area | Usually a fix in place | Points to a rebuild of that part |
|---|---|---|
| Database access | RLS off or loose: write policies, test with two accounts | Records have no owner, so no rule can say "only my data" |
| Keys | A secret key in the front end: rotate it, move the call server-side | Never a reason on its own |
| Payments | Unverified or duplicate webhooks: signature check, event log, amount check | The browser marks orders as paid |
| Code | Messy screens that work: clean up as you go | Every fix breaks something else; no part can be tested alone |
| Search | Screens behind a login: browser rendering is fine | Public pages that must rank render only in the browser |
| Mobile | The web app is enough for now | You need the App Store and the app is a wrapped website (4.2) |
| Platform | The code exports to a repository you own | The backend cannot be exported or moved |
Rebuilding a part doesn't stop the business. We rebuilt Barber & Co's Tilda store in place: the orders and every product link stayed, and new pages went live on temporary addresses before swapping in. It is a store, not a vibe-coded app; the method carries over.

What does vibe coding cleanup involve?
Five steps. You can stop after any of them and keep everything built so far.
- Review the code, the money flow and the user path. With read access, we go through the code, database, payment setup, hosting and the screens on the way to paying, then list the risks by harm.
- Stabilize the live app. The payment path first, then error reports, downtime alerts, backups and a dashboard, built into the existing app.
- Rewrite only what fails. One part at a time behind the same screens, keeping data and accounts. Sound AI-written code stays.
- Hand over. Access, docs and the dashboard are yours.
- Support. We watch the alerts, fix what breaks and ship features.
Before any of it, the code moves to a repository you own. Hosting, domain and payment accounts stay in your name; we work as invited members.
Vladimir Babin, who wrote this guide, has shipped production iOS and macOS apps for more than 10 years and leads legacy-to-modern migrations on production codebases. A vibe-coded app is young legacy code: nobody fully knows how it works, and it already holds real data. Senior partners lead the work, with vetted specialists per project. Our own payment service follows the rules above: it verifies the signature on every notification from the provider and checks the paid amount against the order before marking it paid. Each paid order also pings the team in Telegram.
ChessProfi, where chess players in Germany find a tournament, sign up and pay, runs on the stack many AI builders generate: React and Vite, Supabase, Stripe and Sentry for errors. We built it from zero, so it is not a rescue; what carries over is knowing where this stack leaks.

We take on this work for apps that already take money: see vibe coding cleanup and rescue or send us a note about your app.
How much does it cost to fix a vibe-coded app?
We don't publish a price, because apps differ too much for a range to help. Three things drive it: the state of the payment path, how much code has to be rebuilt and how many integrations there are. After the review you get an estimate for your app, split by step.
Some costs come from providers. As of November 1, 2026, Supabase's pricing page lists Pro from $25 a month; Free projects have no backups and pause after "1 week of inactivity"; point-in-time recovery costs "$100 per month per 7 days retention". These are Supabase's list prices, not ours. Hosting and AI usage come on top.
Not fixing has a price too. In California, if "nonencrypted and nonredacted personal information was stolen in a data breach" because a business failed to keep reasonable security, consumers can sue for actual or statutory damages, says the Attorney General's CCPA page, updated August 28, 2026. Since January 1, 2025, adjusted for inflation, statutory damages run from $107 to $799 per consumer per incident, so for a breach touching 10,000 Californians the ceiling is $7.99 million. Before suing for statutory damages, a consumer must give the business 30 days to cure.
If the review points to rebuilding a mobile app, our iOS app development cost guide has market ranges. For comparable quotes from several studios, use our one-page software brief template.
Which privacy laws apply to a vibe-coded app in the US and the UAE?
How the code was written doesn't matter: personal data brings the usual rules.
- UAE. The PDPL, Federal Decree-Law No. 45 of 2021, in force since January 2, 2022, doesn't apply in free zones with their own data protection laws, such as DIFC and ADGM. Article 20 requires appropriate technical and organizational measures. Under Article 9, the controller reports a breach to the people affected and to the regulator, which the law calls the UAE Data Office; a processor reports it to the controller.
- California. The CCPA lets consumers sue after a breach caused by poor security, as above.
- EU users. Under GDPR Article 33, a breach goes to the regulator "without undue delay and, where feasible, not later than 72 hours" after you become aware of it.
You cannot report a breach you cannot see; logs and alerts show what it touched.
Vibe-coded app security checklist before launch
Any item you can't tick before real users and payments is where the work starts.
- Ownership. Code in a repository you own; hosting, domain, database and payment accounts in the company's name.
- Access. RLS on every table in an exposed schema, policies tested with two accounts, no errors in the Security Advisor.
- Secrets. No secret keys in
VITE_orNEXT_PUBLIC_variables or in Git history; legacy Supabase keys replaced before the end-of-2026 deadline. - Payments. Signatures verified on the raw body, event IDs logged, the amount checked against the order, the paid status written only by the server.
- Backups. Daily backups on a paid plan or your own scheduled exports, a separate copy of uploads, one tested restore.
- Agents. AI coding tools work on a development copy without production credentials.
- Alerts. Errors reach a person, downtime triggers an alert, failed payments get a weekly review.
- AI costs. Rate limits and per-user quotas on every endpoint that calls a model.
- Mobile. In-app account deletion, more than a wrapped website, and Google Play's closed test for new personal accounts.
- Privacy. A breach plan: who decides, who notifies whom and how fast.
To have a partner run this list on your live app, see our vibe code rescue service or tell us about your app. Comparing studios in the UAE? Our guide to choosing an app development company lists what to ask.
Questions we get asked
Is a Lovable app safe to launch?
It can be, once someone checks what Lovable leaves to you. Its docs say the built-in scans cannot guarantee complete security and that you are responsible for your app's security. Before real users and payments, confirm Row Level Security on every table, no secret keys in the front end, verified payment webhooks and working backups. In a 2025 scan of 1,645 Lovable projects, researcher Matt Palmer found 170 that let anyone read or write their data.
Should I fix or rewrite my vibe-coded app?
Most apps need a fix, not a rewrite. Access rules, leaked keys and payment handling can be repaired inside the existing code. A rebuild is justified when the data model is broken at the root, for example when records have no owner a security rule could check, or when the app sits on a platform it cannot leave. Even then, rebuild one part at a time behind the same screens and keep the data and accounts.
How much does it cost to fix a vibe-coded app?
It depends on the state of the payment path, how much code has to be rebuilt and how many integrations the app has, so an honest estimate comes after a code review, split by step. Running costs are separate: as of November 1, 2026, Supabase lists its Pro plan from $25 a month and point-in-time recovery at $100 a month per 7 days of retention. These are Supabase's list prices, not ours.
Can a vibe-coded app take payments safely?
Not until someone has checked. The common faults are secret keys shipped to the browser, database tables any signed-in user can read, and payment notifications accepted without checking who sent them. Stripe warns that without signature verification an attacker can send fake events that fulfill orders or grant access. Verify signatures, log event IDs because Stripe may deliver an event more than once, and compare the paid amount with the order.
Is the Supabase anon key safe to put in the browser?
The publishable key, and the legacy anon key it replaces, may sit in the browser only because Row Level Security limits what it can reach. Without RLS, the same key can read and change the table. The secret key, or the legacy service_role key, bypasses every RLS policy and must never ship in a browser, an app or a Git repository. Supabase is deprecating the anon and service_role keys by the end of 2026.
What should we do if our vibe-coded app leaked user data?
Rotate every exposed key, close the hole, usually Row Level Security, and work out what was read. Then follow the notice rules for your users. With users in the EU, the GDPR asks for notice to the regulator within 72 hours where feasible. The UAE PDPL requires notifying the UAE Data Office and the people affected. In California, a breach caused by poor security can bring statutory damages of $107 to $799 per consumer per incident. Call counsel the same day.
Sources
- AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks, Veracode Research Reveals · Veracode, 2025
- GenAI Code Security Fall 2026: The Ceiling Moves, But on the Low-Hanging Fruit · Veracode, 2026
- Statement on CVE-2025-48757 · Matt Palmer, 2025
- CVE-2025-48757 Detail · NIST National Vulnerability Database, 2025
- Methodology: How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platforms · Escape, 2025
- Hacking Moltbook: The AI Social Network Any Human Can Control · Wiz, 2026
- An AI-powered coding tool wiped out a software company's database, then apologized for a 'catastrophic failure on my part' · Fortune, 2025
- Development and production databases · Replit Docs, 2026
- Cursor-Opus agent snuffs out startup's production database · The Register, 2026
- Row Level Security · Supabase Docs, 2026
- Performance and Security Advisors · Supabase Docs, 2026
- Understanding API keys · Supabase Docs, 2026
- Database Backups · Supabase Docs, 2026
- Pricing · Supabase, 2026
- Env Variables and Modes · Vite, 2026
- How to use environment variables in Next.js · Next.js Docs, 2026
- Receive Stripe events in your webhook endpoint · Stripe Docs, 2026
- OWASP Top 10:2025 · OWASP Foundation, 2025
- LLM10:2025 Unbounded Consumption · OWASP GenAI Security Project, 2025
- Security · Lovable Documentation, 2026
- FAQ · Lovable Documentation, 2026
- Deployment, hosting, and ownership options with Lovable · Lovable Documentation, 2026
- App Review Guidelines · Apple Developer, 2026
- App testing requirements for new personal developer accounts · Play Console Help, 2026
- Federal Decree by Law No. (45) of 2021 Concerning the Protection of Personal Data · UAE Legislation, 2021
- California Consumer Privacy Act (CCPA) · State of California Department of Justice, 2026
- Updated Monetary Thresholds in CCPA · California Privacy Protection Agency, 2025
- Regulation (EU) 2016/679 (GDPR), Article 33 · EUR-Lex, 2016
Share this article

About the author
Vladimir Babin
Co-founder, Head of Mobile
Leads native iOS and mobile apps, from idea to App Store.


