Lovable app before launch checklist

If you built a SaaS with Lovable, Bolt, v0, Cursor, Replit, or another AI app builder, do not treat a working preview as a production-ready product. Preview proves the happy path. Launch readiness means the app survives real users, bad inputs, failed payments, bots, and direct API calls.

This checklist is for founders who are about to share a Lovable app publicly, collect user data, connect Stripe, use Supabase, or call paid APIs like OpenAI, Anthropic, Resend, Twilio, or ElevenLabs.

Why Lovable apps need a launch checklist

Lovable is useful because it gets a product working quickly. That speed is also why critical production details can be skipped. Recent founder and developer discussions around vibe-coded apps keep circling the same theme: AI-generated code can look clean while hiding security, auth, billing, and deployment gaps.

On Reddit, builders are already making tools that scan vibe-coded apps for hardcoded API keys, dead files, duplicated logic, missing tests, and missing deployment basics. Another Reddit thread asked whether a security scanner for Lovable, v0, and Bolt solves a real problem after the author found exposed API keys, missing auth checks, and no input validation in AI-built apps.

That is the right instinct. A scanner can catch obvious issues. A senior developer review is still useful because production risk often lives in the logic between systems: which user owns which row, whether Stripe updates access, whether a server route checks auth, and whether a bot can burn your API budget.

1. Supabase RLS and data isolation

If Lovable created your database in Supabase, Row Level Security is the first thing to check. Supabase's public anon key is designed to be visible in browser code, but the safety model depends on correct RLS policies. If RLS is missing or too broad, one user can often read or modify data that belongs to another user.

What to check

• RLS is enabled on every table that stores user or business data.
• Policies check ownership, not just whether someone is logged in.
• User A cannot read, update, or delete User B's records.
• Storage buckets have policies, not just database tables.
• No policy uses broad logic like USING (true) for private data.

Minimum test

Create two test accounts. Add data as User A. Log in as User B. Try to access User A's records through the UI and through direct API calls. If User B can see User A's data, block launch.

2. API keys and frontend bundles

AI-generated apps often solve integration problems by placing keys where the browser can use them. That is fine for publishable keys, but dangerous for secret keys. Stripe secret keys, Supabase service role keys, OpenAI keys, Anthropic keys, Resend keys, and Twilio auth tokens must never ship to browser JavaScript.

What to check

• No service_role Supabase key in frontend code.
• No Stripe sk_live or sk_test key in frontend code.
• No OpenAI, Anthropic, Resend, Twilio, SendGrid, or GitHub token in browser bundles.
• No secret value prefixed with NEXT_PUBLIC_, VITE_, or REACT_APP_.
• No secrets committed to Git history.

Search your deployed JavaScript bundle and your GitHub repository for obvious key patterns. If a secret was exposed, rotate it. Deleting it from the current file is not enough.

3. Stripe checkout and webhooks

Stripe checkout working once does not prove billing is safe. Your app needs to handle the full payment-to-access flow: successful checkout, recurring payments, failed payments, cancellations, refunds, retries, duplicate events, and plan changes.

What to check

• Checkout sessions are created server-side.
• Stripe webhook signatures are verified with the raw request body.
• The webhook is idempotent, so duplicate events do not double-apply changes.
• invoice.payment_failed changes account state or starts a clear grace-period flow.
• customer.subscription.deleted removes or schedules removal of paid access.
• Your app reads paid access from backend subscription state, not from a success redirect.

For more detail, read the dedicated guide: Stripe webhook returns 200 OK but subscription access does not update.

4. Auth checks on every server route

Client-side auth is user experience, not a security boundary. A user can bypass your frontend and call API routes directly. Every server route that reads or mutates private data should verify the session and authorization server-side.

What to check

• Logged-out users cannot access private screens or API data.
• Every API route that reads user data checks authentication.
• Every API route that mutates data checks both authentication and ownership.
• Admin routes enforce roles server-side, not only in the UI.
• Password reset, magic links, and OAuth redirects work on the production domain.

5. Server-side validation on forms and API routes

Frontend validation is helpful, but attackers do not have to use your frontend. They can call your endpoints directly with malformed data, oversized payloads, unexpected fields, or scripts.

What to check

• Every endpoint validates input on the server.
• Length limits exist for free-text fields.
• Unknown fields are rejected or ignored intentionally.
• Database writes use structured APIs or parameterized queries.
• User-generated text is escaped before rendering as HTML.

6. Rate limits, CAPTCHA, and cost caps

Public endpoints are not just a security risk. They are a cost risk. A bot can spam signup, contact forms, password reset, AI-generation routes, email sending, image generation, or SMS notifications.

What to check

• Rate limits on auth routes, public forms, and paid API routes.
• CAPTCHA or bot protection on public forms.
• OpenAI, Anthropic, and other paid APIs have usage limits and alerts.
• Email and SMS providers have sane sending limits.
• Abuse logs are visible enough that you can spot spikes.

7. CORS, security headers, and production error handling

Many generated apps leave permissive development defaults in production. CORS may allow every origin. Error messages may expose SQL queries, table names, stack traces, or internal file paths.

What to check

• CORS is restricted to your production domain and local development origins.
• Security headers are configured: HSTS, X-Frame-Options or CSP frame protections, X-Content-Type-Options, Referrer-Policy.
• Production errors shown to users are generic.
• Detailed errors go to server logs or error tracking, not the browser.
• Debug endpoints like /debug, /status, /info, or /metrics are removed or protected.

8. Repo hygiene and deployability

Some launch blockers are not glamorous. They still matter. Reddit builders are already scanning vibe-coded apps for dead files, duplicated logic, undeclared imports, missing .gitignore, missing tests, and files with names like final_v2.py.

What to check

• .env and local secrets are ignored by Git.
• The app installs from a clean clone.
• Dependencies are declared in the package files.
• Dead experiments and duplicate auth or billing logic are removed.
• Build and deploy commands are documented.
• There is at least a basic manual test checklist for signup, login, payment, failed payment, cancellation, and data isolation.

What scanners catch and what they miss

Scanners are useful. They can find obvious issues quickly: hardcoded secrets, missing RLS, permissive CORS, missing auth middleware, source maps, debug flags, known dependency vulnerabilities, and exposed environment files.

But scanners can miss business logic. They might not know whether your subscription should revoke access immediately or after a grace period. They might not understand your tenant model. They might not know whether a Supabase policy is correct for your product. They might not catch a webhook that returns 200 but writes to the wrong user row.

Use scanners for the mechanical 80%. Use senior review for the judgment-heavy 20%: data ownership, payment state, failure paths, auth flows, and launch risk.

Final pre-launch checklist

1. Test two-user data isolation in Supabase.
2. Search deployed bundles and Git history for secret keys.
3. Verify Stripe webhook signatures and failed-payment behavior.
4. Call private API routes while logged out and as the wrong user.
5. Validate every form and mutation server-side.
6. Add rate limits and CAPTCHA to public abuse surfaces.
7. Restrict CORS and hide internal errors from users.
8. Run a clean install and remove dead code before handoff.
9. Add monitoring or at least visible server logs before public launch.

When to ask for help

Ask for a launch audit if your Lovable app has real users, real payments, private user data, paid API calls, or a public launch date. The earlier you check, the cheaper the fixes usually are.

Sources used

• Supabase docs: Row Level Security
• Supabase docs: API keys
• Stripe docs: receive webhook events
• Reddit: preflight scanner for vibe-coded apps
• Reddit: security scanner for Lovable, v0, and Bolt code
• Reddit: AI-built open-source app asking for human expert review
• Indie Hackers: AI-built apps and production-readiness checks
• Indie Hackers: security layers before touching production