← Blog · Published Oct 19, 2026 · Updated Oct 31, 2026 · by the Vibefixr team

The launch checklist for apps built with Lovable, Bolt, Cursor, Replit and v0

Building the app was the fun part. Before real users and real money arrive, run through these 14 checks. Each one says why it matters, how to tell if it applies to you, a short fix where there is one, and a link to the full guide. Test in the live app, not the preview: most of these problems only show up in production.

Short on time? Do security and payments first. Those are the ones that leak data or lose money.

Security

1. Every table has RLS that actually blocks other users

• Why it matters: Your Supabase publishable key is public by design, so Row Level Security is the only lock on your data.
• How to tell: Supabase’s Security Advisor shows “Table publicly accessible” or “allows unrestricted access”, or a second test account can see the first account’s data.
• Quick fix: Enable RLS on every table and give each one policies that match who should see what. Never “fix” errors by turning RLS off.
• Read more: Is your Lovable app leaking user data? How to tell if your Supabase RLS is broken

2. No secret key in your JavaScript

• Why it matters: The Supabase secret / service_role key skips every RLS policy. In the frontend, it’s a master key for anyone.
• How to tell: Search the loaded JavaScript for sb_secret_ or service_role, or run the free Supabase key checker.
• Quick fix: Move anything that needs it to an Edge Function or server, then rotate the key in the order Supabase recommends.
• Read more: Leaked your Supabase service_role key in a vibe-coded app? What to do now · Check your app now with the free Supabase key checker

3. RLS doesn’t hide your users’ own data

• Why it matters: The opposite failure: policies that match nothing make queries return an empty list with no error.
• How to tell: The rows are in the Table Editor, but the app gets [].
• Quick fix: Check that a SELECT policy exists for the role the request really uses, and that a session exists when the query runs.
• Read more: Supabase returns an empty array but the table has data? It’s usually RLS

Supabase’s October 30, 2026 change

4. New tables get deliberate grants

• Why it matters: From October 30, 2026, new tables in the public schema aren’t reachable through the Data API until access is granted. Existing tables keep working.
• How to tell: A new feature fails with 42501 permission denied for table … while older features work.
• Quick fix: Grant each role only what it needs, together with RLS and policies, in the same migration. Never grant everything to everyone.
• Read more: Supabase’s October 30 change is live: a 5-minute checklist for new tables

Deploy

5. The live site isn’t blank

• Why it matters: Environment variables that exist in the editor are often missing from the production build.
• How to tell: A white page on the live URL, and a red error in the browser console.
• Quick fix: Set every VITE_ variable on your host and rebuild. Check the publish directory and asset paths.
• Read more: Lovable app shows a blank white screen after deploy? Here’s why

6. Refreshing any page works

• Why it matters: Single-page apps need the host to serve index.html for every route.
• How to tell: / loads, but refreshing /dashboard gives a 404.
• Quick fix: Add the SPA fallback rule for your host (for example public/_redirects on Netlify).
• Read more: Bolt.new app shows 404 when you refresh a page? Here’s why

7. Server functions have their production secrets

• Why it matters: Local secrets in supabase/functions/.env aren’t deployed.
• How to tell: An Edge Function returns 500 or logs undefined only in production.
• Quick fix: Set the secrets in the Supabase dashboard or with supabase secrets set. No redeploy needed.
• Read more: Your Supabase Edge Function works locally but fails in production: why

8. API calls go to your live API, not localhost

• Why it matters: Code written next to a local backend often hard-codes http://localhost, and APIs on another domain must allow your live origin (CORS).
• How to tell: The Network tab shows requests to localhost, or the console says “blocked by CORS policy”, only on the live site.
• Quick fix: Read the API address from an environment variable (VITE_ or NEXT_PUBLIC_) and rebuild; allow your exact production origin on the server.
• Read more: Your app calls localhost or hits a CORS error after deploy: here’s why

Login

9. Login doesn’t send users to localhost

• Why it matters: Supabase sends users to the Site URL when the redirect isn’t on the allow list, and it starts as localhost.
• How to tell: After Google login, or from a reset email, the browser opens localhost:3000.
• Quick fix: Set Site URL to your live domain and add your production and preview URLs to Redirect URLs.
• Read more: Google login sends users to localhost after you publish? Here’s the fix

10. The app doesn’t freeze after login

• Why it matters: Awaiting other Supabase calls inside the login listener could deadlock older supabase-js versions.
• How to tell: Login succeeds, then an endless spinner or blank page, often only after refresh.
• Quick fix: Run a current supabase-js (2.107.0 or later) and keep slow work out of the login listener.
• Read more: Your Lovable app freezes or goes blank right after login: here’s why

Payments

11. Paying actually unlocks the feature, in live mode

• Why it matters: Access usually depends on a webhook reaching your backend. Test and live mode use separate keys, endpoints and signing secrets.
• How to tell: Stripe shows the payment as succeeded, but the account is still on the free plan. Stripe’s Event deliveries tab shows failed deliveries.
• Quick fix: Make a real live-mode purchase before launch and check the delivery log.
• Read more: Stripe says “paid”, your app says “free”: why the feature didn’t unlock

The basics the free health check covers

12. HTTPS, security headers and no public source maps

• Why it matters: Quick outside checks that AI-built apps often miss.
• How to tell: Paste your live URL into the free health check. It also looks for secret keys in your JavaScript.
• Read more: Run the free health check

After launch: keep it working

13. You have a way back when an AI fix breaks things

• Why it matters: Fix-and-break loops are where launched apps quietly get worse.
• How to tell: The same bug returns after two or three AI fixes, or the AI suggests turning off security to make an error go away.
• Quick fix: Revert to the last working version, ask in Chat mode before building, and change one thing per prompt.
• Read more: Stuck in a loop where every AI fix breaks something else? Here’s when to stop

14. You know your options before something breaks

• Why it matters: When a live app breaks, you end up choosing a fix under pressure. Some problems are a free settings change; others need someone who reads the code.
• How to tell: You don’t know whether your problem is a two-minute fix or what a developer would charge for it.
• Quick fix: Check the free fixes first, then compare fixed prices, freelancers and agencies before you need one.
• Read more: How much does it cost to fix a Lovable or Bolt app?

Want us to run the checklist for you?

The free health check covers the outside of your app. Everything else (RLS, grants, secrets, login flows, webhooks) needs a look at the repo and settings, which is what the Audit does.

FAQ

Information here is checked against official docs at the time of writing. Platforms change, so verify against the linked sources.