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.
A broken preview or deployment can have several causes: configuration, dependencies, data access or a regression. Use the checks below to narrow the problem from evidence. These examples are not a measured failure rate for Lovable or a diagnosis based on project size.
Is Lovable down, or is it your app?
Before you debug anything, rule out an outage. Check Lovable's status page and their X account. If the editor will not load, previews are failing for everyone, or publishing hangs across projects, it is them, not you, and the only fix is patience.
If the platform is available, save the current state and investigate the first reproducible error. Lovable has version-history and security tools, but confirm what the available recovery point contains. A restored code version is not a substitute for a verified database backup.
Lovable support can help when the platform misbehaves: builds that hang, editor bugs, billing. What support cannot do is re-architect the app the model built for you. When the app is up but wrong, the sections below are the honest map.
Diagnose it: six symptoms, six causes
Use this table to identify possible causes and useful checks. Symptoms can have more than one cause; confirm the diagnosis with logs and a reproducible example.
| Symptom | Possible cause to investigate | Can you fix it yourself? |
|---|---|---|
| Works in preview, breaks when deployed | Possible cause: 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 | Data access may be misconfigured. Check table grants, enabled RLS and policies using authorised test records. With RLS enabled, no policies normally means API access through a publishable key is denied. Check the actual access path rather than diagnosing exposure from a key or policy count alone. | 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 | Incomplete instructions, incompatible edits, missing dependencies or stale assumptions can cause regressions. Session length alone does not diagnose the cause. Preserve the current state, read the logs and compare the last changes against the previously working version before making another patch. | Pause repeated unsuccessful patches. Save the state and inspect the error and recent changes; seek help if the cause remains unclear. |
| Login randomly fails | Possible cause: 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 | Data access may be misconfigured. Check table grants, enabled RLS and policies using authorised test records. With RLS enabled, no policies normally means API access through a publishable key is denied. Check the actual access path rather than diagnosing exposure from a key or policy count alone. | No, but you can stop the bleeding today. Run the triage checklist below right now. |
| App is suddenly slow | Possible cause: 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. |
When to pause and investigate
If repeated attempts are not resolving the same error, pause new changes. Save the current state and identify a known working version. Inspect what changed before deciding whether to revert, repair or seek help.
Incomplete instructions, incompatible edits, missing dependencies or stale assumptions can cause regressions. Session length alone does not diagnose the cause. Preserve the current state, read the logs and compare the last changes against the previously working version before making another patch.
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.
- Review table grants, RLS settings and policies together, using authorised test accounts and test records. In Supabase, enabled RLS with no policies normally denies API access through a publishable key; it does not make the table public. Disabled RLS requires checking whether the relevant roles have access. Test both permitted and denied paths before release.
- Review actual exposed secrets. Search locally for credential values and inspect how they are used, without sharing them in chat or screenshots. Service-role and other privileged secret keys belong on trusted server infrastructure. Variable names or publishable keys alone do not prove exposure; rotate actual exposed secrets and review their use.
- Check access boundaries with authorised test records. In a staging environment, verify that logged-out and unauthorised test accounts cannot read or change protected data. An intentionally public endpoint is not automatically a breach. Confirm the intended permissions before drawing a conclusion.
- Verify backups and recovery. Keep an authorised backup and test restoration separately before risky changes. A CSV table export may help preserve records but does not include every schema constraint, file, user identity or recovery requirement. Confirm what can be restored rather than promising data will survive any outcome.
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. Run our vibe-code security checklist to map every gap before writing a line of fix.
What a rescue actually costs
There is no verified market-price dataset behind this guide. Request an audit-based quote that separates investigation, urgent security work, repair, testing, deployment and ongoing support. The tool used to build the app does not determine the price.
Compare the proposed investigation, security checks, test coverage and handover rather than the supplier's location or job title. A low quote may exclude important work, while a high quote does not establish quality. Ask each supplier to explain its assumptions and exclusions.
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. Built with a different AI tool? The same rescue framework applies: Bolt, Cursor, v0, and Replit each have their own guide.
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. Check critical paths on proposed changes so covered regressions can be caught before release. Tests reduce risk within their coverage; they do not guarantee that every bug or production issue will be detected.
- 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?
An agent may help with an isolated, reproducible bug. Keep the change small and verify it against a saved baseline. Repeated unsuccessful patches are a reason to investigate the logs, dependencies and access controls, not proof of a specific context-window failure.
Should I start over or fix what I have?
Compare rescue and rebuild after inspecting the code, data and requirements. Existing product decisions may be reusable, but missing Git history alone does not require a rebuild. Compare migration risk, retained functionality, testing and ongoing costs before choosing.
How long does a rescue take?
A reliable timeline needs an agreed scope after inspection. Access, the failure to reproduce, affected data, integrations, security issues and required release checks all influence it. Ask for an investigation milestone, a repair estimate and a staged release plan; these are not guaranteed turnaround times.
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.