Why your Lovable app works locally but fails in production

The preview is not a small version of production

It is a different machine with different assumptions. Lovable's preview holds your environment variables for you, keeps a database connection open, and runs a build step you never had to think about. None of that travels with your code when you move it somewhere you control.

So the first deploy fails, and the error message is usually useless — a blank white page, or a build log ending in a module that cannot be found. The instinct is to assume the code is broken. It generally is not.

The four things that actually break

1. Environment variables are missing. Your app asks for a Supabase URL or an API key, gets undefined, and crashes on the first render. The fix is to set every variable on the host, which means first knowing what the full list is.
2. A development URL is hard-coded somewhere. Something still points at localhost or at the preview domain. It worked in the preview because that was where it lived.
3. The build fails on a dependency the preview supplied. The preview environment had a package installed that your package.json never listed, so the build works there and nowhere else.
4. The database connection has no pooling. Serverless hosts open a new connection per request. Without pooling you exhaust the connection limit quickly, and the failure looks intermittent rather than total, which makes it much harder to diagnose.

How to find out which one it is

Read the build log rather than the page. A white screen tells you nothing; the build log tells you whether the app failed to compile or failed to start. Those are different problems with different fixes.

• Failed to compile: a missing dependency or an import that does not resolve. This is a build problem.
• Compiled, then crashed on start: a missing environment variable, nearly always.
• Compiled, started, blank page in the browser: open the browser console. It is usually a failed network request to a URL that does not exist outside the preview.
• Works, then fails under any traffic at all: database connections.

Do you have to leave Lovable to fix this?

No. Deploying somewhere you control does not mean abandoning the tool you built with. Plenty of people keep designing screens in Lovable while the deployment lives on their own host and their own domain. Some later changes — moving secrets to server-side functions in particular — cannot be round-tripped back into the original tool, so decide early whether that editing workflow matters to you.

What this costs to fix

A deploy of an app that already works is a same-day job. If it does not run at all, the honest first step is finding out why before anyone quotes you to fix it — which is what an audit is for.