Lovable app not working? The ten causes we see most, and how to fix each

Your Lovable app worked last week. Today it shows a blank page, a spinner that never stops, or a form that submits and does nothing. In almost every case we get called into, one of four things happened: the AI edited more than you asked, something changed in Supabase, you published and the live version behaves differently from the preview, or a setting exists in one environment and not the other.

Here are the ten causes we find most often, in the order we check them. Each one tells you what you will see, why it happens in Lovable projects, and how to fix it. Most apps are back within the first five.

1. A Supabase migration that half applied

What you see. Pages that list or save data fail. The console reports a column or table that does not exist, or a query that used to return rows returns nothing.

Why it happens. When you ask Lovable for a new field or feature, it changes the code and generates a database migration together. If the migration fails part way, or runs against the preview database but not the one the published app uses, the code expects a schema the database does not have.

How to fix it. In the Supabase dashboard for the project the published app uses, compare the tables and columns with what the code queries. Look for failed migrations. Apply the missing change by hand, or have Lovable regenerate it and watch it run. Reload with the console open and confirm the errors are gone.

2. Secrets that exist in preview but not in production

What you see. The preview works, then the published app fails on the first action that talks to an outside service: sign in, payment, email, an AI call.

Why it happens. Keys and configuration are stored per environment. A key pasted into the preview does not exist in the published environment, so the request goes out with an empty value and fails with a generic error.

How to fix it. List every external service the app uses, check the published environment's secrets one by one, add what is missing, then publish again. Settings are usually read at build time, not on every request.

3. The AI edited a shared file while fixing something else

What you see. You asked for a small change on one screen and now sign in, navigation or the whole layout is broken.

Why it happens. A prompt to fix a button can lead the model to rewrite the file that contains it, and that file may also hold the auth provider, the router or the layout. With no tests to say what must keep working, nothing stops it.

How to fix it. Find the recent edits that touched shared files and revert to the last version that worked. Re-apply the small change with a narrower prompt that names the exact component and states what must not change. If the code is in GitHub, a diff of the last commit shows this in seconds.

4. An edge function that times out or throws

What you see. One action hangs, then fails, while the rest of the app is fine.

Why it happens. Lovable often puts server-side logic in Supabase edge functions. One that calls a slow external API, loops over too much data or throws on an unexpected input will time out or error, and the front end spins forever.

How to fix it. Open the function logs in the Supabase dashboard and trigger the action again. The log shows the exception or timeout. Fix the cause, add a timeout to outbound calls, and make the front end show a real error message.

5. Row Level Security on, with no policies

What you see. Queries return empty results or a 401 even though the data is in the table, often right after someone enabled RLS to clear a security warning.

Why it happens. RLS with no policies blocks every read and write for normal users. The app only worked because the table was wide open.

How to fix it. Write a policy for each table the app touches. A typical one for user-owned rows:

create policy "Users read their own rows"
on public.orders for select
using (auth.uid() = user_id);

Test with two different accounts. If the warning was "RLS disabled in public", read what it means and how to fix it properly first.

6. Auth redirect URLs still point at the preview

What you see. Google sign in, magic links or password resets work in preview and fail on the live domain, usually bouncing back to the preview address.

Why it happens. Supabase and every OAuth provider keep an allow-list of redirect URLs. The preview address was added when the feature was built; the published domain was not.

How to fix it. In the Supabase auth settings, set the site URL to the published domain and add it to the redirect list. Do the same in the Google, Apple or other provider console.

7. A third-party key in test mode

What you see. Payments succeed with a test card and fail with a real one. Emails send in preview and vanish live. AI features return an authorisation error.

Why it happens. Stripe, Resend, OpenAI and similar services issue separate test and live keys. The app was built with test keys and the live ones were never added. For payments there is a second trap: the webhook that marks an order as paid must be registered for the live endpoint, with its own signing secret.

How to fix it. Add the live keys to the published environment, register the live webhook and its secret, and run one real transaction end to end.

8. A build that fails without telling you

What you see. You published, but the site still shows the old version, or nothing at all.

Why it happens. A type error, a missing dependency or an import of a file the AI renamed stops the build. The preview keeps running the last good version, so it is easy to miss.

How to fix it. Open the deployment log and read from the first red line, not the last. Fix that one thing, publish again, and confirm the deployment succeeded before testing.

9. Caching and a stale service worker

What you see. The app is broken for you but works for someone else, or works in a private window and not your normal one.

Why it happens. Progressive web app features or aggressive caching keep an old bundle in the browser, which then calls the new API and fails.

How to fix it. Test in a private window. If that works, unregister the service worker in the developer tools or ship a version bump that forces a refresh. If the app does not need offline behaviour, remove the service worker.

10. The custom domain

What you see. The app loads on the Lovable address but not your domain, or on www but not the bare domain, or the browser warns about the certificate.

Why it happens. A custom domain needs the right DNS records, an issued certificate and one decision about whether www or the bare domain is canonical. Any of the three can be half done.

How to fix it. Match the DNS records exactly to what the hosting settings ask for, wait for the certificate to show as issued, and redirect the non-canonical host to the canonical one.

How to stop it happening again

• Export the code to a GitHub repository you own, for history, diffs and a place to run checks.
• Add one smoke test for the core flow: sign in, do the main thing, sign out. Run it before every publish.
• Keep a short changelog of prompts that touched shared files.
• Use separate Supabase projects for preview and production, with separate keys.

When to hand it over

Bring in engineers when users can see data that is not theirs, when payments are involved, when the same bug returns after every fix, or when the app costs you more than a few hours a week. Those are the signs the codebase has stopped converging, and more prompting will not change that.

Where QLTech fits

We take over Lovable projects that have reached that point: a fixed-price audit that finds the real causes, the fixes, the security and deployment work that stops them recurring, and a repository your team can own. Start with our AI app rescue service or send us a short brief and we will reply with a written scope.