From vibe coding to production: harden your AI-built app, or rebuild it?

Andrej Karpathy named it in his post of 2 February 2025: describe what you want, accept the model's changes without reading the diffs, paste errors back in, and let the code grow past your own understanding. He called it fine for "throwaway weekend projects". The trouble starts when the weekend project gets customers.

Here is what each tool says it is, read on 13 October 2026. I'm not ranking them.

Lovable's stack changed this year. Its upgrade guide says TanStack Start, which renders pages on the server, became the default for new projects on 13 May 2026. Older projects are client-rendered React and Vite.

The public record is short but consistent. These are the incidents I could source to the people involved or to a vulnerability database:

• Open tables in Lovable apps. Matt Palmer's statement on CVE-2025-48757, published 29 May 2025, describes a March 2025 scan of 1,645 projects from Lovable's showcase. It found 303 endpoints across 170 projects, about 10.3%, where Supabase tables could be read or written without signing in, because row level security was missing or wrong. On one app, the researchers inserted a record marked as paid, skipping Stripe.
• The CVE. The NVD record carries a CVSS 3.1 score of 9.3, critical, from MITRE, and is tagged disputed: Lovable's position is that each customer is responsible for their own app's data.
• The same pattern at scale. Escape, a security testing vendor, wrote on 29 October 2025 that it analysed over 5,600 public apps from vibe coding platforms and found more than 2,000 vulnerabilities, over 400 exposed secrets and 175 instances of personal data, which it calls a lower bound.
• A platform flaw. Wiz reported on 29 July 2025 that private Base44 apps could be joined by anyone who knew the public app ID. Wix fixed it within 24 hours.
• A deleted database. On 20 July 2025, Replit's chief executive Amjad Masad wrote on X that its agent, working in development, had deleted data from a production database, and that Replit was rolling out automatic separation of development and production databases.

That's the confirmed part. My reading: none of it is exotic. On the OWASP Top 10:2025 it is A01 Broken Access Control, still first, and A02 Security Misconfiguration. OWASP's introduction to the 2025 list adds a new category, A10 Mishandling of Exceptional Conditions: failing open, and logic that breaks when the unexpected happens.

I sort every finding into three gates. The first four must pass before a single real user signs up, because they leak or lose data. The next four make it a product people can use. The last two keep it alive and affordable.

That's why each gate has an evidence column. "We turned on RLS" isn't evidence. "My second test account got an empty list" is.

Most builder apps talk to the database straight from the browser with a public key. That's legitimate only when the database does the guarding. Supabase's API keys guide says the publishable key is safe to expose because it reaches only what row level security allows, and asks you to enable RLS on every table before you deploy. The secret key bypasses every policy and must never be in a browser, a shipped app or source control. Its row level security guide adds that a table in an exposed schema without RLS is readable and writable by any role with a grant on it.

So the first hour of any review goes like this:

1. List every table and confirm RLS is on.
2. Read each policy against the product's rules, not against "a policy exists". Palmer's point was that checking for presence gave false comfort.
3. Sign up as users A and B. As B, try to read, change and delete A's rows by calling the API directly, not through the interface.
4. Move every write that matters (payments, roles, plan limits, invites) to a server check. Payment status comes from Stripe's webhook, never from a field the browser can set.
5. Search the built JavaScript for keys. Vite's docs say anything prefixed VITE_ is exposed in client code; Next.js does the same with NEXT_PUBLIC_, as in my checks for AI-generated code.
6. Rotate any key that ever reached the browser or a commit. Deleting it doesn't remove it from history.

The builders now help. Lovable's security docs describe a scan on publish that checks database access rules, while saying the tools can't guarantee complete security. GitHub's push protection is on by default for user accounts pushing to public repositories. I use both, then test as user B anyway.

Builders give you good version history for code, and founders assume it covers data too. Bolt's database docs say plainly that Version History doesn't support database restores, and that restoring an earlier version won't change your current databases.

What I set up before launch:

• Separate production data. Replit's database guide now provisions separate development and production environments. Whatever the tool, nobody, human or agent, experiments on customers' rows.
• Backups you've restored. Supabase's backups page lists daily backups on Pro (7 days kept), Team (14) and Enterprise (up to 30). Free-plan projects get none, and Supabase recommends regular exports kept off-site.
• Migrations in files, so the schema can be rebuilt from the repository and reviewed like code.
• One rehearsal. Restore last night's backup into a scratch project and time it.

What does the person see when the payment provider times out, the model returns nothing or the list is empty on day one? In a generated app, usually a blank panel or a raw error.

The code side, state by state, is in reviewing AI-generated interface code. The product side is a short walk on a phone:

• Every screen on the core flow, empty, with one sentence and one action.
• Every failure says what happened, whether anything was saved and what to do next.
• Every call to a third party has a timeout and fails closed: no access granted because a check errored.
• A small admin view, so support never means editing production rows. I argued for it in how to scope an MVP.

I build to WCAG 2.2 at level AA, a W3C Recommendation since 5 October 2023, updated 12 December 2024. Three criteria catch builder apps often: Target Size (Minimum), 24 by 24 CSS pixels; Accessible Authentication (Minimum), which rules out sign-in that blocks paste or password managers; and Focus Not Obscured (Minimum), for sticky headers covering the focused field. The component fixes are in my WCAG 2.2 checklist for React.

For speed I use Google's Web Vitals thresholds: main content within 2.5 seconds (LCP), a response to input within 200 milliseconds (INP) and layout shift of 0.1 or less (CLS), at the 75th percentile of visits. If your public pages sit on Lovable's older template, its upgrade to server rendering is worth it for search alone; Lovable puts most upgrades at 10 to 35 credits.

I don't ask for full coverage on an inherited app. I ask for end-to-end tests on the paths that cost money when they break: sign-up, sign-in, password reset, payment, and the one job the product exists for. Playwright runs them in a real browser on every pull request, and a failure blocks the merge.

Then the pipeline: code in a repository your company owns, a preview link for every change, migrations applied by the pipeline rather than by hand, error alerts that reach a person, and a rollback route for code beside the restore you rehearsed for data.

I use AI tools daily, and a person who knows the design reviews every change. That review is what how I harden and ship Next.js apps adds to a builder's speed.

Production bills are mostly metered, from four places.

• Builder credits. Replit's AI billing docs describe effort-based pricing, where complex requests cost more, with budget limits that act as hard caps. Lovable gives 10 free security fixes, each back 24 hours after use, then fixes use credits.
• Hosting. Vercel's spend management page, updated 18 September 2026, warns that setting a spend amount doesn't stop usage unless you also turn on pausing of production deployments, and pausing doesn't stop v0 usage billed to the team.
• Database. Supabase's pricing lists Pro from $25 a month with $10 of compute credits and a spend cap on by default; free projects pause after a week of inactivity.
• AI model calls. Every user action has a price, so I add per-user limits and log tokens per call.

My rule: every bill has a named owner, an alert at half the budget and a cap.

I make this call area by area, not for the whole app. The screens are often the best part of a builder app; the data layer is usually the weakest.

The rebuild signal I trust most: every fix breaks something two screens away. The structure is wrong, and starting again on a clean data model, keeping the designs, the copy and what users taught you, costs less than patching.

This week, do three things. Run the two-account test on your three most sensitive tables. Search your live JavaScript for anything that looks like a secret key. Write down how you would restore yesterday's data. If all three pass, you're hardening, not rebuilding.

If any fail, or you'd like me to take the app the rest of the way, bring the repository to a free 30 minute intro call about my design and build work for founders, or read how I work first. A written scope and one fixed quote follow, with the code and every account in your company's name.

Can a vibe-coded app go to production?

Yes, if it passes the checks any app would: access control tested with two accounts, no secrets in the browser, backups you have restored, real error states, accessibility, speed and tests on the paths that cost money. Many builder apps can be hardened. The data model decides whether hardening or a rebuild is cheaper.

Is Lovable safe for production apps?

It can be, but safety depends on your configuration. Lovable's own docs say its scans can't guarantee complete security and recommend a professional review for sensitive data. The most common public failure was missing or wrong row level security on Supabase tables, so test every policy as two different users before launch.

Do I need to rewrite my vibe-coded app?

Not by default. Keep what is sound, usually the screens and the copy, and fix the layers underneath. Rebuild when ownership, tenancy or roles are wrong at the table level, when sign-in was hand-written, or when every fix breaks something elsewhere. Decide area by area, not for the whole app at once.

How do I back up a Lovable, Bolt or Replit app?

Treat code and data separately. Sync code to a Git repository you own. For data, use the database's own backups: Supabase gives daily backups on paid plans and recommends regular exports on the free plan. Bolt's version history doesn't restore databases, so rehearse one real restore before launch.

How much does it cost to run a vibe-coded app in production?

It depends on usage, because builder credits, hosting, database and AI model calls are mostly metered. Published examples: Supabase Pro starts from $25 a month with $10 of compute credits, and Replit charges Agent work by effort. Set alerts and hard caps on every service before you invite users.

Who coined the term vibe coding?

Andrej Karpathy, in a post on X on 2 February 2025. He described accepting an AI model's changes without reading them and letting the code grow beyond his own understanding, and said it suited quick, disposable projects. The term then spread to AI app builders such as Lovable, Bolt, v0 and Replit.

I read every source on 13 October 2026. Tool descriptions follow each vendor's docs; features change often. Incident figures come from the researchers' write-ups and NVD; Escape and Wiz are security vendors. The gates and the keep, fix or rebuild table are my method, not measured data. I found no reliable public data on how often vibe-coded apps are hardened rather than rebuilt.

• Andrej Karpathy, post on X coining vibe coding, 2 February 2025, date read 13 October 2026: x.com
• Matt Palmer, statement on CVE-2025-48757, 29 May 2025, date read 13 October 2026: mattpalmer.io
• NIST, National Vulnerability Database, CVE-2025-48757, date read 13 October 2026: nvd.nist.gov
• Escape, methodology for vulnerabilities in apps built with vibe coding platforms, 29 October 2025, date read 13 October 2026: escape.tech
• Wiz Research, critical vulnerability in Base44, 29 July 2025, date read 13 October 2026: wiz.io
• Amjad Masad, post on X about Replit Agent and production data, 20 July 2025, date read 13 October 2026: x.com
• OWASP, Top 10:2025 and its introduction, date read 13 October 2026: owasp.org, top10.owasp.org
• Lovable, Cloud, Git sync, security and TanStack Start upgrade docs, date read 13 October 2026: docs.lovable.dev, docs.lovable.dev, docs.lovable.dev, docs.lovable.dev
• Bolt, Bolt Database help page, date read 13 October 2026: support.bolt.new
• Vercel, v0 docs and spend management, date read 13 October 2026: v0.app, vercel.com
• Replit, Agent, add a database and AI billing docs, date read 13 October 2026: docs.replit.com, docs.replit.com, docs.replit.com
• Cursor, docs home, date read 13 October 2026: cursor.com
• Supabase, row level security, API keys, backups and pricing, date read 13 October 2026: supabase.com, supabase.com, supabase.com, supabase.com
• Vite, env variables and modes, date read 13 October 2026: vite.dev
• Stripe, webhooks, date read 13 October 2026: docs.stripe.com
• GitHub, about push protection, date read 13 October 2026: docs.github.com
• W3C, Web Content Accessibility Guidelines 2.2, date read 13 October 2026: w3.org
• Google, web.dev, Web Vitals, date read 13 October 2026: web.dev
• Microsoft, Playwright, getting started, date read 13 October 2026: playwright.dev