Your Lovable app broke in production. Start here.

The preview build worked. You clicked through every screen, payments went through in test mode, and you shipped. Then real users arrived and something gave way: sign-ups that never complete, records that vanish, a customer who paid and has nothing to show for it. You did not do anything wrong. The preview and production are different machines running different configuration, and Lovable only ever showed you the first one.

Lovable is good at what it does. It produces a working product surface faster than any studio could, ours included. The failures that reach us are almost never in the screens. They sit in the seams between the app and the services around it — the database's permission layer, the payment provider's callbacks, the auth provider's redirect rules. Five seams account for most of what we see. Each one below comes with a test you can run yourself, today, without hiring us or anyone else.

1. Row-level security is off, and your database is public

Lovable apps ship on Supabase, and Supabase's browser client talks to the database directly using a publishable anon key. That design is safe only when row-level security is switched on and policies restrict every table. Generated apps routinely skip that step, because the app works fine without it — right up until someone other than you reads the whole table.

This is the failure behind the biggest vibe-coding incident of the year: in February 2026, researchers at Wiz found the Moltbook database exposed with roughly 1.5 million API keys readable, through exactly this misconfiguration. The app worked. The data was public.

Test it: open your app in a private browser window, sign in as nobody, open developer tools, and note the supabase URL and anon key from the network tab. Request one of your tables with curl using only that key. If rows come back that a stranger should not see, stop reading and fix this first.

2. Secrets shipped in the client bundle

A browser app cannot keep a secret. Anything compiled into the JavaScript bundle — a Stripe secret key, a Supabase service-role key, an OpenAI key — belongs to whoever opens view-source. Generated code reaches for whichever key makes the call succeed, and in a preview there is no one hostile watching. In production there is.

Test it: load your production app, view page source, and search the bundle for sk_live, service_role and api_key. Any hit is a leaked credential. Rotate it today; moving it server-side is the actual fix.

3. Auth works on the preview domain and nowhere else

OAuth providers and magic-link emails are allowed to redirect only to URLs on an allowlist. The preview domain got added automatically while you built. Your production domain often did not. The symptom is an app where you — still holding a session from the build — get in fine, while every new user bounces off Google sign-in or clicks a magic link that dead-ends. You will not see it until you test as a stranger.

Test it: sign up from a clean browser profile on the production URL, with an email you have never used. Do it once a week. Most founders have never once signed up for their own app the way a customer does.

4. Payments confirm in the browser instead of the backend

The checkout page saying success proves the payment provider took the money. It does not prove your app recorded it. The record has to come from the provider's webhook: delivered to your endpoint, signature verified, matched to the right user, written exactly once even when the webhook retries. Generated integrations tend to treat the browser redirect as the source of truth and skip the webhook path entirely — which is why the money can be real while the order is not.

This one failure is common enough that we wrote it up separately, with the full four-step trace from checkout session to database write. If your specific symptom is charged-but-no-record, read that piece next; the test below is the short version.

Test it: open your Stripe dashboard, find the webhook endpoint, and look at the delivery attempts. Failures, retries, or no endpoint at all — each one is an order your app may have missed. Then find one real payment and check the matching row exists in your database.

5. Environment seams: the configuration production never got

Environment variables set in the preview and never copied to production. CORS rules that allow the old domain. A third-party service still pointing its callbacks at a URL that no longer exists. None of this is visible in the code, which is why it survives review. The app is correct; its surroundings are wrong. These are the quickest fixes on this page and the hardest to find without a checklist, because every one produces a different, unrelated-looking symptom.

Test it: list every external service your app touches — database, auth, payments, email, storage — and for each one ask: which URL does it call back to, and which keys does production hold? Any answer containing the word preview is a live bug.

Should you fix it in place or rebuild the broken part?

Not everything deserves a rebuild. The screens Lovable produced are usually fine and rewriting them burns money for no user-visible change. The decision rule we apply on rescues: anything that holds money, identity or records — payment paths, auth, the database schema and its policies — gets engineered properly. Everything else stays as generated until it earns a rewrite. Founders who follow that split keep most of what they built and spend on the part that was actually dangerous.

The platform's own security record matters here too. Lovable had a rough spring: The Register reported an app on the platform exposing data on 18,000 users through inverted access control in February 2026, and TNW covered a wider exposure window over the weeks that followed. The lesson is not that the tool is bad. It is that the platform will not check your seams for you — the five above are yours to close, whichever builder generated the app.

If you would rather hand it over

This is the work our App Rescue practice does all day. The first audit is free: send the app, and we trace one real payment end to end — checkout session, payment intent, webhook signature, idempotency key, database write — plus the five seams above, and return written findings within 48 hours. The findings are yours either way. If you take them to another engineer, they will know exactly where to start; nothing about the audit locks you to us.