Lovable, Bolt & v0 Pre-Launch
Checklist: Is Your App Ready?

Quick answer: an app built with Lovable, Bolt or v0 is ready for real users when a stranger can't read anyone else's data, no secret key ships to the browser, payments are confirmed on the server, sign-up emails reach the inbox, you have a backup you've actually restored, and you own the code and every account behind it. The AI gets you to a working demo fast. These are the checks it most often leaves undone. Below is the checklist I run on my own projects, in order of how much it hurts if it fails.

Why "it works" isn't the same as "it's ready"

An AI builder optimizes for what you can see: the screen does what you asked. Security and reliability failures are invisible in a demo, and they show up only when someone goes looking for them.

Someone already has. In May 2025, Semafor reported that two researchers scanned 1,645 apps built with Lovable and featured on its site. 170 of them let anyone access information about their users: names, email addresses, financial information and secret API keys for AI services. The issue was registered as CVE-2025-48757 with a 9.3 (critical) score. Lovable disputes it, on the grounds that each customer is responsible for protecting their own app's data. Which is the point of this checklist: that responsibility is yours.

It isn't a Lovable-only problem. In October 2025, the security firm Escape analyzed more than 5,600 public apps built with vibe coding platforms and found over 2,000 vulnerabilities, more than 400 exposed secrets and 175 cases of exposed personal data, including medical records and bank account numbers.

1. Database access: can a stranger read your users' data?

Most of these apps store their data in Supabase (Postgres). The browser talks to the database directly using a public key. That's by design, and it's only safe if Row Level Security (RLS) is turned on for every table, with policies that actually restrict who sees what. Supabase's own production checklist puts it bluntly: tables without RLS and reasonable policies let any client access and modify their data.

"RLS enabled" is not the same as "RLS correct". A policy that allows every row passes a quick scan and still lets everyone read everything.

• RLS is on for every table, including the ones you think nobody uses.
• Every policy ties rows to the logged-in user (or to an explicit role), not to "anyone authenticated".
• Users can't promote themselves. Fields like role, plan, credits or "paid" can't be written from the browser.
• File storage is private unless a file is meant to be public, like a product image.
• Test it with two accounts. Log in as user A and try to open user B's records by changing an ID in the URL. Then try again while logged out. If anything loads, you have a leak.

If you're on Lovable, it now runs a security scan every time you publish. In 10 to 15 seconds it checks for missing RLS policies, authorization gaps and database misconfigurations. Lovable is clear that this basic scan doesn't analyze your code for logic flaws. Run its deep scan before launch, and do the two-account test anyway.

2. Secrets: is a key in the browser that shouldn't be?

Supabase has two kinds of keys. The publishable (or "anon") key is meant to be public. The secret (or "service_role") key bypasses every RLS policy, and Supabase's instruction is simple: never put one in a browser, a shipped application or source control.

The same goes for every other paid key your app uses: OpenAI, Anthropic or Gemini, your Stripe secret key, your email provider. These belong on the server (an edge function or API route), never in the code that runs on the user's device. In the Lovable case above, exposed AI keys meant strangers could run up charges billed to the app's owner.

• Check your live site: open your browser's developer tools and search the JavaScript files for "secret", "service_role" and "sk_". Anything that turns up is a problem.
• If you find one, rotate it first (generate a new key and revoke the old one), then move the call to the server. Removing it from the code isn't enough: it's already been public.
• Set spending limits on every AI provider account, so a leak costs you an email alert instead of a five-figure invoice.

3. Sign-up and login: the edge cases

• Email confirmation is on, so nobody can sign up with someone else's address.
• Password reset works end to end, from the email to the new password.
• One-time codes expire in an hour or less (Supabase's recommendation).
• Admin pages are protected by the database, not by the menu. Hiding a button doesn't stop someone from opening the URL.
• Sign-up, login and reset have CAPTCHA if the app is public, so bots can't create thousands of accounts.

4. Payments: never trust the success page

This is the mistake that costs real money. Many AI-built apps unlock the purchase when the customer lands on the "thank you" page. Stripe's documentation explains why that's unreliable: a customer can pay and lose their connection before the page loads, and some payment methods confirm later.

• Fulfill orders from webhooks (the events Stripe sends to your server), and verify each webhook's signature. Without verification, a forged event can unlock orders nobody paid for.
• The price comes from your server, never from the browser, so nobody can edit the amount before checkout.
• Subscriptions: a cancellation or a failed renewal actually removes access.
• Before launch, switch from test keys to live keys and make one real purchase, then refund it.

5. Email: will users actually get it?

Supabase's built-in email service is for testing: it sends 2 emails per hour. On launch day, most of your sign-ups would never get their confirmation. Connect your own email provider (Resend, Postmark or Amazon SES, for example) on your own domain, and set up SPF, DKIM and DMARC so the emails don't land in spam. Even with your own provider, Supabase starts you at 30 new users per hour; raise it if you're planning a launch.

6. Backups and uptime: what happens on your worst day?

• Know your plan. Supabase's Free plan pauses projects after 7 days of low activity, and Free projects can't download backups. On Pro ($25/month), projects aren't paused and you get daily backups kept for 7 days.
• Restore a backup once, into a test project. A backup you've never restored is a hope, not a backup.
• Keep your own copy of the database somewhere you control, on a schedule.
• Turn on error monitoring (Sentry or similar) and an uptime check, so you hear about problems before your customers tell you.
• Protect the accounts: two-factor authentication on Supabase, your hosting, your domain registrar and GitHub, and a second owner on each.

7. Ownership: do you actually own your app?

• The code is synced to a GitHub repository in your account.
• The Supabase project, the hosting and the domain are in your name or your company's.
• The Stripe account belongs to your business, with your bank details.

If a freelancer or an agency set any of this up under their own accounts, transfer it before launch, while everyone is still friendly.

8. SEO and AI search: can Google see your pages?

If people should find your app through Google or ChatGPT, the content has to be in the page the server sends, not only drawn later by JavaScript. How each tool handles it:

• v0 generates Next.js apps, which can render each page on the server.
• Lovable made server rendering (TanStack Start) the default for new projects on May 13, 2026. Older React + Vite projects send a nearly empty page; Lovable serves pre-rendered copies only to verified search engines and social preview bots, and other tools see much less. Lovable offers an upgrade path for older projects.
• Bolt depends on the framework your project uses, so check it.

The test takes ten seconds: open your site, right-click and choose "View page source". If your headline and main text aren't in there, many crawlers won't see them either. While you're there, check that each page has its own title and description.

9. The legal minimum

A privacy policy that matches what you actually collect, terms of service, and a way for users to delete their account and their data. If you handle health, financial or children's data, talk to a lawyer before launch. That's beyond what any checklist can cover.

A 30-minute self-check before you launch

1. Create two test accounts and try to open each other's data, logged in and logged out.
2. Search your live JavaScript files for secret keys.
3. Make a real purchase with live keys, close the tab halfway through payment, and confirm the order still registers. Then refund it.
4. Sign up with a fresh email address: the confirmation and the password reset both reach the inbox, not spam.
5. Open your Supabase dashboard and check the plan, the backups, the Security Advisor and who the project owners are.
6. View the source of your homepage and confirm your main text is in it.

When to bring in an engineer

If something on this list failed and you're not sure why, or if your app handles payments, health data or other businesses' data, it's worth having someone review it before real users arrive. Fixing a leak before launch is a configuration change; fixing it after is an incident.

I build with these tools every day. Gobernia.ai, a SaaS where four AI agents meet every month to advise a business, is my own product, and this is the checklist I run before anything of mine goes live. If you'd rather have me go through it for you, my AI app rescue starts with a $249 production review: a written report of what's broken, what's risky, what's fine and what it would cost to fix, delivered in 3 business days. If you hire me for the fix, the review is credited.

Frequently asked questions

Is Lovable safe for production? It can be. Lovable builds on Supabase, which is used in production by many companies. The risk isn't the platform; it's the configuration the AI leaves behind, especially database access rules, secret keys and payments. Run the checks above before real users or real money arrive.

Is it safe that my Supabase key is visible in the browser? The publishable (anon) key is meant to be public, as long as Row Level Security is on and your policies are correct. The secret (service_role) key must never be in the browser: it bypasses every access rule you have.

Does Lovable's security scan make my app secure? It catches the most common problems, like missing RLS policies, in seconds. Lovable itself says the basic scan doesn't analyze your app's logic. Treat a pass as a good start, not a guarantee, and test with two accounts.

Do I need to pay for Supabase before launch? If you have real users, yes. The Free plan pauses inactive projects and doesn't let you download backups. Pro costs $25 a month and includes daily backups.

Can I keep building with Lovable, Bolt or v0 after launch? Yes. Many teams keep using the AI builder for interface changes and bring in an engineer for the parts that touch data, payments and security. What matters is that every change gets reviewed before it reaches your users.

How long does it take to make an AI-built app production-ready? It depends on what the review finds. Configuration problems, like access rules, keys and email, usually take days. Problems in the data model or in how payments are built take longer. That's why the review comes first: you get a fixed price before any work starts.