Lovable app not working? How to find what broke and get it fixed

A Lovable app can look finished in the preview and then fall apart when real people sign up, a payment goes through or you move it to your own domain. The good news is that most of these failures come from a short list of causes, and several of them can be found without reading any code. This page explains what to check yourself, how to tell when a developer is the quicker route, and how to hand the project over so they can start straight away.

Start by writing down exactly what is broken

Before you change anything, describe the failure precisely. "Login is broken" is hard to act on; "new users land on a blank localhost page after clicking the confirmation email" points almost straight at the cause.

Note four things:

• Where it fails: the Lovable preview, the published Lovable address, or your custom domain.
• Who it fails for: every user, new users only, or one particular account.
• When it started: the last prompt or setting you changed before it broke.
• What the browser says: open the developer tools (F12, or right-click and choose Inspect), look at the Console tab for red errors, and check the Network tab for requests marked 401, 403 or 500. Take screenshots, but crop out any keys or customer details.

If the problem appeared right after a prompt, Lovable's version history lets you go back. This restores code, not your database, so tables or policies a later prompt created will remain.

The most common reasons a Lovable app stops working

Sign-up and login fail on the live site

Lovable apps usually rely on Supabase for accounts. When login works in the preview but not on your domain, the usual suspect is the Site URL and Redirect URLs under Authentication settings in Supabase. If your live address is missing there, confirmation and password reset links send people to the wrong place.

Two other frequent causes: the built-in Supabase email sender is meant for testing and stops sending after a small number of messages, so a live app needs its own SMTP provider; and Google sign-in fails for most people while the Google Cloud consent screen is still in testing mode, because only listed test users can log in. Our Supabase auth and RLS page covers these in more depth.

Data is missing, or visible to the wrong people

Supabase protects tables with Row Level Security (RLS). If RLS is on but no policy lets the current user read a row, the app gets an empty list rather than an error, so pages simply look blank. The opposite problem is more serious: if RLS is off, or a policy allows everyone, anyone who opens the browser tools can read or change that table using the public key already in your app. Paste your policy SQL into the Supabase RLS Checker to spot open tables, and see AI-generated app security issues if you think data has been exposed.

Keys and environment variables

Lovable projects use Vite, which only exposes variables whose names start with VITE_ to browser code. Anything with that prefix is public by design. That is fine for the Supabase URL and anon key, but a Stripe secret key, an OpenAI key or the Supabase service role key must never end up there. If you move the app to another host, those values also have to be added in that host's settings, because .env files are often not part of the repository. Run your code through the Secret Leak Scanner to check for keys that should not be in it.

Build or deploy errors after leaving Lovable hosting

When you export to GitHub and deploy on Netlify, Vercel or similar, three problems come up often. A page shows a 404 when refreshed, because single-page apps need a rewrite rule that sends every route to index.html. The build fails because the host uses a different Node.js version. Or the custom domain does not resolve because DNS records at the registrar still point elsewhere.

Edge functions fail quietly

Tasks such as sending emails or calling an AI API often live in Supabase Edge Functions. Typical faults: a secret never added to the function's settings, missing CORS headers so the browser blocks the call, or a change that was never redeployed. The function logs in Supabase usually show the real error.

Payments go through but nothing changes in the app

With Stripe, the app normally learns about a payment through a webhook. If the webhook endpoint is not registered in the Stripe dashboard, the signing secret is wrong, or test keys are mixed with live keys, customers pay and the app never unlocks anything. Stripe's webhook page lists each delivery attempt and its response, which tells you quickly whether the problem is on the Stripe side or in your function.

Prompts going round in circles

You ask Lovable to fix an error, a different error appears, and the original one returns two prompts later, with each round using credits. The AI works from a slice of the project and cannot see settings that live in Supabase, Stripe or your DNS, so it may keep rewriting code that was never the problem. Stop, restore the last version that worked, and ask for one change at a time with the exact error text. If a few careful attempts do not move things forward, the cause is probably outside the code.

When it makes sense to bring in a developer

Consider getting help when any of these apply:

• Real customer data may have been visible to other users.
• Real money is involved and payments are unreliable.
• The same bug returns after restoring and re-prompting.
• You need background jobs, a move to different hosting, or something else prompting does not handle well.

For a rough sense of size before you talk to anyone, try the Rescue Effort Estimator. The guide on why Lovable, Bolt and v0 apps break in production explains the underlying patterns.

What a rescue developer will usually check first

Someone experienced with Lovable projects will typically:

1. Connect to the GitHub repository, install dependencies and run a production build locally to see every error at once.
2. Open the Supabase project and list each table with its RLS status and policies.
3. Compare the migrations in the repository with the live database, since prompts sometimes change one without the other.
4. Search the code and its git history for secret keys.
5. Read the edge function logs and Stripe webhook deliveries.
6. Send you a short written list of findings and a suggested order of work.

How to hand the project over

Connect the Lovable project to GitHub and invite the developer to the repository as a collaborator. Invite them to your Supabase organisation and, if needed, to Stripe as a team member with a limited role. Do not paste keys or passwords into chat; access through invites can be removed later, and you should plan to rotate keys once the work is done. The guide on giving a developer access without sharing passwords walks through each service, and the Handover Checklist Generator builds the document for you.

Post your Lovable app as a takeover

If you would rather have someone take it from here, post your takeover for free. Mention Lovable and Supabase, describe what works, list the symptoms you noted, and say what "finished" means to you. Developers and agencies who rescue AI-built apps can then contact you. TakeoverWork only connects people: it does not check developers or handle project money, so read how to evaluate developers who want to finish your app before you agree to anything.