WHAT WE FIND
The six failures behind most Lovable projects
# | Failure | What's happening |
01 | Supabase pointing at a dead project | Login silently fails because the connection string still names a project that no longer exists, or the app is talking to your development project while you're looking at production. |
02 | Auth loops after deploy | Users log in and land straight back on the login screen. The production domain was never added to the site URL and redirect list, so the session is discarded on the way back. |
03 | Security shows green, leaks anyway | Row-level security is enabled and the linter passes, but the policy allows everything — or the app calls the database with a key that bypasses the policy entirely. Nothing looks wrong until someone requests data that isn't theirs. |
04 | White or blank screen | A runtime error the build never caught. The browser console names it in one line. The Lovable chat does not, which is why prompting about it goes nowhere. |
05 | Edge functions failing quietly | Webhooks, confirmation emails and payment updates stop arriving. The app reports nothing, so the first signal is usually a customer asking where their receipt is. |
06 | The prompt loop | The project outgrew what the model can hold in context. It patches what it can see and breaks what it can't, so each fix creates two more problems. |
WHAT WE DO
We read the codebase, not the chat history
An engineer traces the root cause, fixes it, and checks what else is waiting to break — because if one environment gap exists, others usually do.
You get a working app, a written note on what was wrong, and tests so the next prompt can't silently undo it. You keep building with Lovable afterwards; the difference is that something will catch it when it goes wrong.
We won't
✕ | Rewrite a working codebase to bill more |
✕ | Patch the symptom and leave the cause |
✕ | Take work we can't finish |
WHERE YOU ARE
We can pick it up at any stage
Stage | What it looks like |
Prototype | The app demonstrates the idea and the experience works. Nothing behind it is ready for anyone but you. |
Functional MVP | The core flows work. The technical gaps are there but nothing has forced them into the open yet. |
Stabilisation | Bugs, data problems, auth failures and architectural weaknesses are surfacing. This is where most people find us. |
Production | Secured, tested, configured, deployed and safe for real users. |
Continued development | New features and maintenance, with someone who knows the codebase. |
Most Lovable projects arrive at stabilisation. A few arrive already live and failing. Both are normal.
Inside the report
Every finding names the file and the fix
Ranked by severity, written so it's useful to whoever fixes it — including if that isn't us.
Severity | Finding | Detail |
Critical | Row-level security allows all reads | The profiles policy is USING (true). Any authenticated user can read every row, including emails and phone numbers. |
Critical | Service role key in the client bundle | A key that bypasses every access rule is shipped to the browser. Anyone can read it from the network tab and query the database directly. |
High | Auth redirect excludes the production domain | Login succeeds and the session is discarded on redirect, producing the loop your users are reporting. |
High | Stripe webhook signature unverified | The endpoint accepts any request. Subscription state can be changed by anyone who finds the URL. |
Medium | No error boundary on the app root | A single render failure blanks the whole page instead of the one component that broke. This is usually the white screen. |
Medium | Query inside a render loop | Fine at fifty rows. The dashboard will time out somewhere around two thousand. |
Can you fix this yourself?
Sometimes, and we'd rather you did. Try these first.
Problem | Try |
Blank screen | Open the browser console on the live site. The real error is usually there, not in the build log. |
Auth redirect loop | Add your production domain to both the site URL and the redirect URL list in Supabase. |
Nothing saving | Check the Supabase project your app connects to is the one you're actually looking at. |
⚠ Stop and get help if you've been on the same break for more than two hours, or the app is live and users are affected. At that point it's structural, and no prompt will reach it.
How it runs
Six steps, and you own it at the end
Step | What happens | |
01 | Audit | We read the codebase and map what's actually there. Free, 48 hours. |
02 | Triage | Findings ranked by severity, plus an honest keep-or-rebuild call. |
03 | Harden | Close the access-control holes and separate staging from production. |
04 | Stabilise | Fix the bugs the AI keeps recreating, by reading the code. |
05 | Test | A regression suite, so the next AI edit can't silently break things. |
06 | Handover | You own it. We document what changed and walk you through it. |
The rule fades from bright mint to near-black across the six steps. Don't equalise it.
You don't need a technical brief
Any one of these is enough to start:
What you have | What it tells us |
Lovable project | The current state of the application |
GitHub repository | Code and change history — the most useful single item |
Live URL | What's actually happening in production |
Preview URL | Whether it behaves differently before deploy |
Screenshots | The visible error |
Error messages | Where to start looking |
Feature list | What's unfinished |
If you're not sure what's wrong, that's fine. "The app doesn't work properly" is a valid starting point — working out which part is broken is the audit's job, not yours.
Before you send anything
Question | Answer |
Can you work from the Lovable project, or do you need GitHub? | Either. Connecting to GitHub is easier for us and better for you regardless — it means your code exists somewhere other than inside one platform. |
What if you tell me it needs a rebuild? | Then that's the audit's answer and you're free to take it anywhere. We'd rather lose the work than sell a rescue that doesn't hold. Most Lovable projects don't need one — the product logic is usually sound and the problems are in the layer underneath. |
Will it break again the next time I prompt? | Less likely. We hand back tests and patterns that catch regressions early, so you can keep building with the rails in place. |
Will you sign an NDA? | Yes, mutual, before you send anything. We don't use client code and we don't build competing products. |
My Lovable project history disappeared. | Recoverable more often than not, especially if the project was ever connected to GitHub. Send us what you have. |
The person who built it isn't around any more. | Common, and one of the clearer cases for an audit. We work out what the application does from the code, document the parts that matter, and hand you something a team can maintain. |
I used several AI tools on the same project. | Also common — Lovable for the interface, Cursor or Claude Code for changes. It usually means two or three competing patterns in one codebase. We reconcile them. |
My app is live and customers are affected right now. | Say so when you send the repository. Live incidents jump the queue. |
Send us the repository
You'll get what's wrong, what's urgent, what's cosmetic, and an honest view on whether it's worth fixing or rebuilding — including if the answer is that you don't need us.
Read access is enough. Mutual NDA first if you'd prefer.
No charge. No obligation. Reply within 48 hours.
Also broken?
Bolt.new · Replit · Cursor · v0 · Base44 · Supabase · Works in preview, breaks after deploy · Security audit