Vibe coding to production: the checklist before you launch
Short answer
Before taking a vibe-coded prototype (built in Lovable, Replit, Bolt, v0, or Emergent) to production, check six things: real authentication instead of a demo login, fully wired payments and webhooks, Supabase Row Level Security policies if that's your backend, database constraints and data validation, a deploy process with rollback and error monitoring, and cleanup of duplicate or dead code the AI tool generated. Most of these gaps are invisible in a demo because a single test user never triggers them.
Key Takeaways
- AI app builders (Lovable, Replit, Bolt, v0, Emergent) ship a working demo. The UI is usually fine. What's usually missing only shows up once more than one real user touches the app.
- The most common gap in Lovable and Bolt builds on Supabase is Row Level Security disabled or misconfigured, letting any authenticated user read or write data that isn't theirs.
- A working demo login is not the same as real authentication. Check for password reset, account recovery, and whether sessions actually expire.
- A checkout button that looks right in a demo doesn't mean Stripe webhooks are handled. Test what happens when a payment fails or a subscription renews.
- None of this requires a rewrite. Most prototypes keep their UI and need targeted fixes to auth, payments, data integrity, and deploy safety.
You shipped the prompt, watched Lovable or Replit or Bolt spit out a working app, and it does exactly what you asked. Login screen, dashboard, the core flow. It looks done.
The catch: "looks done" and "ready for someone who isn't you" are different states, and the gap between them is invisible from inside the tool. A demo has one user: you. Production has strangers, at odd hours, doing things you didn't think to test.
TL;DR
Why the demo doesn't catch these
An AI app builder is optimizing for one outcome: you, typing a prompt, seeing something that works. It has no reason to build a password reset flow you never tested, a webhook handler for a payment failure you never triggered, or a database constraint that only matters once two people edit the same record at the same time.
None of that is a flaw in the tool. It's just not what a single-user demo needs. The six checks below are what a multi-user, real-money, real-data product needs instead.
The six things to check
1. Real authentication, not a demo login
A login screen that accepts a password isn't the same as authentication. Check whether sessions actually expire, whether password reset exists, and whether account recovery works if someone loses access. If the answer to any of those is "I'm not sure," that's the gap.
2. Payments that are actually wired, not just styled
A checkout button that looks right in a demo doesn't mean Stripe (or whichever provider) is fully connected. Test what happens on a failed payment, a subscription renewal, and a refund request. If you've never triggered a webhook on purpose, you don't know if it's handled.
3. Supabase Row Level Security, if that's your backend
This is the one we see most often, because Supabase is the default backend behind a large share of Lovable and Bolt builds. Row Level Security policies decide who can read and write which rows in a table. Disabled or misconfigured RLS means any authenticated user can potentially query data that isn't theirs. It's invisible while you're the only person testing the app, and it's usually a fast fix once someone checks for it specifically.
4. Data integrity: constraints, not trust
Does your database stop bad data, or does it trust the frontend to always send the right thing? Foreign keys, validation rules, and constraints at the schema level catch what a UI bug or a malicious request would otherwise let through.
5. Safe deploys: rollback and monitoring
When you push a change, do you find out something broke because a user complains, or because a monitor told you first? A rollback plan and basic error monitoring turn a bad deploy from a scramble into a five-minute fix.
6. Cleanup: duplicate components, dead code
AI builders iterate toward a working result, which usually means duplicate components and dead code pile up along the way. None of it breaks anything today, but it makes the codebase harder for anyone, including you, to maintain six months from now.
Key Insight
What to do with what you find
If you run through the six checks and everything holds up, you're in a good position, ship it. If something doesn't, the next step depends on what you find:
Small, specific gaps (a missing RLS policy, an unhandled webhook): fixable by you or your existing developer in a few days, once you know exactly what to look for.
Several gaps across auth, payments, and data: worth a second set of eyes before you decide whether to fix it piece by piece or scope a focused rebuild.
You're not sure how to check any of this: that's the actual signal, not the number of bugs you can count. A free, manually-reviewed security check tells you which of the six apply before you spend anything on a fix.
We wrote about why this gap exists in the first place in AI coding tools build MVPs, not businesses. This article is the practical follow-up: what to actually check, in order, before you launch.
Not sure what's actually exposed?
Send the URL. A senior engineer checks it manually and replies within 2 business days. Free, no sales call.
Ask an AI
Get an instant summary of this post from your preferred AI assistant.
Frequently asked questions
- If you're technical enough to audit your own auth, payment webhooks, and Supabase RLS policies, yes. Most founders who built with Lovable aren't set up to catch what's missing precisely because it doesn't show up anywhere in the tool's own interface. A second set of eyes, yours or someone else's, is worth it before real users arrive.
- Probably not without checking a few things first: whether sessions actually expire, whether rate limiting exists anywhere, and whether error monitoring is set up so you find out about a broken deploy before your users do. None of that is visible in the Replit preview, because a single developer testing their own app never triggers the failure modes real traffic does.
- Supabase Row Level Security, when the backend is Supabase, which is common behind Lovable and Bolt builds. RLS disabled or misconfigured on a table means any authenticated user can potentially query data belonging to another user. It's invisible while you're the only person testing the app, and it's usually a fast fix once someone actually looks for it.
- No. The UI and basic flows an AI builder generates are frequently fine to keep. What typically needs work is underneath the UI: authentication, payment handling, data validation, and deploy safety. A full rewrite is rarely necessary and usually more expensive and riskier than a targeted fix.
- Run through the six checks in this article: real auth, wired payments, Supabase RLS if applicable, data integrity constraints, safe deploys, and code cleanup. If you can't confidently answer all six, or don't know how to check them, that's the signal it needs a second look before launch, not necessarily a rebuild.
Related articles
On-Demand App Development: Cost, Core Features, and When to Build Custom in 2026
The on-demand economy is a $335 billion market. Building a custom platform costs more than a white-label solution, but it gives you the unit economics and differentiation that marketplace templates can't. Here is what it costs, what to build, and when custom is worth it.
How to Build a Fintech App in 2026: Cost, Timeline, and What to Decide First
A practical guide to fintech app development for operators building payments, lending, investment, or insurance products. Covers cost ranges, SaaS vs. custom thresholds, compliance decisions, and how RaftLabs structures fintech builds.
AI coding tools build MVPs, not businesses
Cursor, Lovable, Bolt, and v0 can build a working demo in an afternoon. But a demo is not a product. Here is what they skip and why it costs 3x more to fix later.