It worked in preview yesterday. The demo is tomorrow morning. And the last four prompts each fixed one thing and broke two others, so now login works but checkout returns a blank screen and you are bargaining with a chat box at 11pm.
You did not do anything wrong. This is the predictable failure mode of every AI app builder once a project passes a certain size, and it happens to technical founders too. The good news is that almost every broken Lovable app breaks in one of six ways, and each one has a known cause and a known fix. Here is how to diagnose yours in the next five minutes, what you can safely do yourself tonight, and what a proper rescue costs when you need one.
Diagnose it: six symptoms, six causes
Find your symptom in the left column. The middle column is what is almost always going on underneath. The right column is the honest answer about whether you can fix it without help.
| Symptom | What it usually means | Can you fix it yourself? |
|---|---|---|
| Works in preview, breaks when deployed | Environment variables or API keys are missing from the deployed environment. Preview had them, production does not. | Sometimes. Copying env vars into your hosting settings is doable if you know which ones are needed. A leaked key is a different problem entirely. |
| Breaks the moment a second user signs up | Supabase Row Level Security is switched off or has no policies, so user data collides or leaks between accounts. | No. Writing correct RLS policies means understanding your schema and your auth model. Guessing here creates data leaks. |
| Every prompt fixes one thing and breaks another | The model's context window is exhausted and the architecture has drifted. It is patching symptoms in code it can no longer see all of. | No. More prompting makes this worse, not better. See the 2 hour rule below. |
| Login randomly fails | Authentication is handled on the client only, or session tokens are being stored and refreshed incorrectly. | Rarely. Token handling bugs are subtle, intermittent, and security sensitive. |
| Database rows visible to everyone | Row Level Security again, and this one is urgent. Any visitor with your public API key may be able to read entire tables. | No, but you can stop the bleeding today. Run the triage checklist below right now. |
| App is suddenly slow | No database indexes, or generated queries fetching data row by row in loops, known as the N+1 problem. | Sometimes. Adding an index is easy. Knowing which index you need, and finding the N+1 queries, is not. |
The 2 hour rule
If you have been prompting in circles for more than two hours on the same break, stop. The problem is architectural, and no prompt will fix it.
Here is why. The model works inside a limited context window. Early on, your whole app fits inside it, so fixes are precise. Past a certain size it cannot see the whole system anymore, so it patches the symptom directly in front of it, and every patch adds new code, new state, and new surface area for the next thing to break. You are not converging on a fix. You are paying tokens to walk in a circle.
The 20 minute triage you can do yourself
Before you pay anyone anything, do these four checks. They are free, they need no code changes, and they tell you exactly how serious your situation is.
- Check your Supabase RLS policies right now. Log in to Supabase, open your project, and look at the policies view for your tables. If any table holding user data says RLS is disabled, or shows zero policies, that table is effectively public. This is the single most common serious problem we see in Lovable apps, and it is invisible from the app itself.
- Search your code for leaked keys. In your repo or Lovable's code view, search for
sk-andservice_role. Secret keys and the Supabase service role key belong on a server, never in frontend code. If either shows up in client code, treat those keys as already public and rotate them. This is not rare: Veracode's analysis of AI-generated code found that roughly 45 percent of it carries vulnerabilities from the OWASP Top 10, the industry's standard list of critical web security risks. - Hit your API routes logged out. Open a private browser window, do not log in, and paste the URL of one of your API endpoints. If data comes back, it comes back for everyone on the internet too. Client-side login screens are a curtain, not a lock.
- Export your data today, before anything else. Download your tables from Supabase as CSV and keep a copy somewhere safe. Whatever happens next, whether it is a fix, a rescue, or a rebuild, your customer list and your content survive.
If checks one and two came back clean, you may genuinely be looking at a small fix. If either failed, you have a security problem first and a bug second, and the order you fix them in matters.
What a rescue actually costs
Honest numbers, because you are about to get quotes from all directions. Across the global market, specialist rescue work on broken AI-built apps typically lands somewhere around USD 2,500 to 6,000 for a standard project. That is a market observation, not a Sonder quote. Your app might sit under that band or well above it, and anyone who quotes you a fixed price before looking at your code is guessing.
The tempting alternative is the very cheap freelancer, and it usually backfires. Most do not have real depth in Supabase and Next.js, which is the stack under nearly every Lovable app. They cannot read what the AI actually built, so they rebuild blind, and you end up paying twice: once for the rebuild, and again for someone to rescue the rebuild.
What actually moves the price is the state of the project, not the length of your feature list:
- No version control. If there is no Git history, there is no record of what changed or when, and every fix starts from archaeology.
- Leaked secrets. Every exposed key has to be rotated across every service that uses it, and anything those keys touched has to be checked.
- Schema chaos. Duplicate tables, missing relationships, and data that needs migrating before the app can be stabilised.
- Compliance. Health data, payments, or children's data raise the bar on what "fixed" has to mean.
And if what you really have is a validated idea that deserves a ground-up build, that is a different conversation about custom app development, not a rescue.
What a professional rescue actually does
A real rescue is not "make the bug go away." It runs in a specific order, because fixing features on top of a broken foundation just breaks them again:
- Security audit first. Read the entire codebase, map every exposed key, open endpoint, and unprotected table before touching anything.
- Secrets rotated. Every leaked or suspect key replaced and moved server-side where it belongs.
- RLS and server-side auth. Row Level Security policies written for your actual schema, and authentication enforced where it counts, on the server.
- Tests and CI. So the next change cannot silently break login the way the last twenty prompts did.
- Staged deploys. A preview environment that is actually configured like production, so "works in preview" starts meaning something.
- Then your feature list. Deliberately last, on ground that can hold it.
Frequently asked questions
Can Lovable fix its own broken app?
Sometimes, for small isolated bugs. But if you have been prompting for more than two hours on the same break, the honest answer is no. Lovable generates code from a limited context window. Once your app grows past what the model can hold in view, every fix is made partially blind, which is exactly how one prompt repairs login and breaks checkout. Architectural problems need a human who can read the whole codebase.
Should I start over or fix what I have?
Fix what you have, in most cases. Your app already encodes hundreds of product decisions that took you weeks to make, and a rebuild throws those away along with your momentum. Starting over only makes sense when there is no version control to recover, the database schema is unsalvageable, or the app is small enough to rebuild in days. A good rescue keeps the product you validated and replaces what is broken underneath it.
How long does a rescue take?
For a typical Lovable app on a Supabase backend, one to three weeks. The first days go to the security audit and secret rotation, because leaked keys cannot wait. Auth and Row Level Security are usually stable within the first week. Tests, CI, and staged deploys follow, and then feature work restarts on solid ground. Messy schemas and compliance requirements extend the timeline.
Do I need to stop using Lovable?
No. Lovable is genuinely good at what it was built for: getting an idea in front of real users fast. The problem is running production traffic and customer data on prototype infrastructure. After a rescue, many founders keep using Lovable for prototypes and landing pages while the production app lives in a proper repository with version control, tests, and staged deploys. Right tool, right stage.