Lovable App Broken After Deploy? 8 Causes and How to Fix Them

Inside Lovable everything looks finished. The preview loads, the buttons work, the demo impressed your co-founder. Then you connect a custom domain, export to GitHub or deploy to Vercel or Netlify — and suddenly you get a blank white page, a 404 on refresh, or users who log in and land nowhere.

This is the single most common situation we see when founders send us a Lovable project. The good news: the causes are predictable. Below are the eight we fix most often, roughly in the order you should check them.

Why the preview lies to you

Lovable's preview runs in a controlled environment that Lovable configures for you: routing, environment variables, the Supabase connection and auth redirects are all set up to work there. The moment your app runs anywhere else, every one of those assumptions has to be re-created by hand. Nothing is "broken" in the code you saw — it simply depended on an environment that no longer exists.

1. 404 when you refresh a page or open a direct link

Lovable apps are single-page applications built with React and Vite. There is one real file, index.html, and React Router decides what to show based on the URL. When someone opens yoursite.com/pricing directly, the hosting server looks for a file called /pricing, does not find it and returns 404.

Fix: add a rewrite rule that sends every route to index.html. On Vercel that is a rewrites entry in vercel.json, on Netlify a _redirects file with a catch-all rule. It takes two minutes, but nobody tells you it is needed.

2. Environment variables are missing on the new host

Inside Lovable, the Supabase URL, the public anon key and other settings are injected for you. On Vercel or Netlify the build runs without them, so the app either fails to build or builds and then crashes in the browser with "supabaseUrl is required".

Fix: copy every variable into the hosting dashboard. In a Vite project, any variable the browser needs must start with VITE_ — a variable without that prefix is simply undefined in the client. Never put secret keys (the Supabase service role key, the Stripe secret key) in VITE_ variables: they end up in the public JavaScript bundle.

3. Login works in preview, but users never come back after sign-in

Magic links, Google sign-in and password resets all redirect the user back to a URL. In Supabase that URL is controlled by the Site URL and the list of allowed Redirect URLs. If those still point to the Lovable preview domain, users on your real domain are sent somewhere else — or get an error about an invalid redirect.

Fix: in Supabase → Authentication → URL Configuration, set the Site URL to your production domain and add every domain you use (production, www and non-www, staging) to the allowed redirects. For Google sign-in, also add the domain in Google Cloud Console.

4. Data shows up in preview but is empty in production — or the opposite

Usually this is one of two things. Either production is connected to a different Supabase project than the one you populated in preview, or Row Level Security (RLS) policies block the requests coming from real, logged-in users.

The second case is often worse than it looks. Many Lovable projects were "fixed" at some point by turning RLS off or adding a policy that allows everything. That makes the app work — and makes every row in that table readable by anyone who has your public anon key, which is in your JavaScript bundle.

Fix: confirm which Supabase project each environment uses, then review RLS table by table. Every table with user data needs RLS enabled and policies that tie rows to auth.uid(). This is the one item on this list that is a security issue, not just a bug.

5. Stripe payments succeed, but nothing happens in the app

The customer pays, Stripe shows the payment, but the account is not upgraded. Payment status should be confirmed by a webhook — a request Stripe sends to your backend — not by the browser. In Lovable projects that backend is usually a Supabase Edge Function.

Typical failures: the webhook endpoint in Stripe still points to a test URL, the webhook signing secret is missing from the function's secrets, the function was never deployed to the production project, or test-mode keys are mixed with live-mode keys.

Fix: check the webhook delivery log in the Stripe dashboard first — it shows exactly which requests failed and why. Then align keys and secrets per environment.

6. The build fails on the server but worked in Lovable

Two classic causes. First, file name case: macOS does not care whether you import ./components/Header or ./components/header, but the Linux servers used by Vercel and Netlify do. Second, TypeScript or ESLint errors that Lovable tolerated but a stricter build command treats as fatal.

Fix: run npm run build locally from the GitHub repository before you deploy. Every error it shows is one your host will show too.

7. Edge Functions fail with CORS errors

When your frontend moves to a new domain, Supabase Edge Functions that only allowed requests from the preview origin start rejecting the browser's requests. In the console it looks like a generic CORS error, which sends people looking in the wrong place.

Fix: handle the OPTIONS preflight request in each function and return the correct Access-Control-Allow-Origin header for your production domain.

8. The site works, but Google and social networks see an empty page

This one does not break anything visibly, so it is discovered late. Because a Lovable app renders in the browser, the initial HTML is almost empty and every page shares the same title and description. Google can render JavaScript, but it is slower and less reliable, and link previews on LinkedIn, Slack or WhatsApp usually show nothing useful.

Fix: at minimum, set unique titles and descriptions per route and add a sitemap. If organic search matters to your business, the real fix is pre-rendering or moving public pages to a framework with server rendering, such as Next.js.

Why "fix it" prompts make it worse

When something breaks after deploy, the natural reaction is to paste the error back into Lovable. The problem is that most of these causes are not in the code Lovable can see: they are in Vercel settings, Supabase dashboards, Stripe configuration and Google Cloud. The AI changes code to compensate, often in several places, and you end up with a new bug and fewer credits. If three prompts in a row have not solved it, the issue is almost certainly outside the codebase.

A quick self-check before you ask for help

• Does a direct link to an inner page return 404? Then it is routing (cause 1).
• Does the browser console mention supabaseUrl or undefined keys? Environment variables (cause 2).
• Do users get stuck after login or after clicking an email link? Redirect URLs (cause 3).
• Is data missing for logged-in users only? RLS (cause 4).
• Does Stripe show failed webhook deliveries? Payments setup (cause 5).
• Does npm run build fail locally? Build errors (cause 6).

When to bring in a developer

If you have gone through the list and the app still misbehaves, or if you found RLS disabled on tables with personal data, it is time for a proper review. We work with Lovable projects through GitHub sync, so you can keep building in Lovable after we fix things — or move to your own stack if the project has outgrown it.

See how we fix and finish Lovable apps — targeted fixes start at $300, and the first code review is free.