My Lovable app works in preview but not in production: the 6 usual causes

It is the single most repeated complaint among people building with AI tools: the app works perfectly in the preview, then you publish it — custom domain, real users — and something core breaks. Login loops. Blank screen. Payments that never confirm.

The good news: this failure is almost never mysterious. The preview environment forgives a set of things production does not, and the list of suspects is short. Here they are, in the order you should check them — whether your app came from Lovable, Bolt, v0, Base44, or a Claude Code or Codex session.

1. Environment variables that only exist in the preview

Everything the preview "just had" — Supabase keys, Stripe keys, OpenAI keys, base URLs — must exist in the final environment too. A missing variable rarely announces itself; it shows up as a blank screen or a silent failure in whatever feature needed it.

Check: list every external service your app talks to, and confirm each key exists in the deployed environment, not just locally or in the platform preview. Watch the naming: a VITE_/NEXT_PUBLIC_ prefix decides whether the variable reaches the browser at all.

2. Auth redirect URLs pointing at the preview

Authentication providers (Supabase Auth, Google OAuth, etc.) keep an explicit allowlist of URLs they will redirect back to. The AI tool registered the preview URL for you. Nobody registered your real domain.

Symptom: login works on the preview, and on your domain it either loops, lands on an error page, or redirects back to the preview URL.

Fix: add the production domain to the provider's redirect/site URL configuration — in the auth provider's settings, not just in your DNS. Then test the full signup and login flow from the real domain in a private window.

3. Supabase RLS: policies that exist in your head only

In preview, with one test user, missing Row Level Security is invisible. In production it is the difference between an app and a public database. This one usually does not break the app — worse, everything works while any user can read any other user's rows.

Check: every table holding user data has RLS enabled and policies actually written. Then prove it: create two accounts and try to read account A's data logged in as account B.

4. Webhooks that were never verified

Stripe payments confirm through webhooks hitting your backend. In the preview, that boundary is rarely exercised for real. In production you need: the webhook endpoint registered for the live domain, the signing secret verified in your handler, and idempotent handling — Stripe retries, and a retry must not create a second subscription.

Symptom: payment goes through in Stripe's dashboard, but your app never upgrades the account.

5. The custom domain itself

Half-configured domains produce the weirdest bugs: works on www but not on the apex, certificate pending so half the assets fail, or the platform still serving the old preview build on the new domain.

Check: certificate issued, both www and apex resolving, and a hard refresh from a device that has never seen the preview.

6. Server code that assumed your machine

If your app came out of Claude Code, Codex or Cursor rather than a hosted builder, add this class: paths that exist only on your laptop, a local database, a port hardcoded, a process that dies on server restart because nothing supervises it. "Works on my machine" is this whole article in one sentence.

When the checklist is not enough

If you have been around this loop for more than a couple of hours — the AI "fixes" it, something else breaks, repeat — the problem is usually no longer one setting but the structure underneath. That is the point where a fixed-price audit is worth more than another hundred credits: 450 EUR, 48 working hours, and a written list of what is actually broken, what is a security risk, and what each fix costs. We finish AI-built apps for a living — we do not rebuild them from scratch, and the audit tells you whether fixing or rebuilding is even the right question for yours.

And before you put real users on it, run through the security checklist for vibe-coded apps — the failures there are quieter than a blank screen, and considerably more expensive.