Your Lovable app almost certainly doesn’t need rebuilding. Lovable builds clean screens and relies on a service called Supabase for logins, data and behind-the-scenes logic — and that is where most real problems live: who is allowed to see which data, where users are sent after logging in, secret keys, and the joins between the screens and the database. Those are findable and fixable one at a time.
Lovable’s output is consistent, so its failures are consistent too. These are the ones that come up again and again.
Either every user can see every other user’s records, or nobody can see anything and the page shows an empty list. Both come from the database’s access rules (Supabase calls them row-level security policies) never being written for how the app is actually used.
The login redirect, a database key or a secret used by behind-the-scenes code was set up for the preview address and never for the published one.
Large components carrying state for several features, so each prompt-driven edit changes more than it was asked to.
Logic Lovable moved into Supabase ‘edge functions’ that is missing a setting or never reports its errors — so the screen just waits.
Stripe and email flows wired to test keys or stubbed responses, never exercised with a real account.
Ten minutes, before asking anyone for help. If any of these is unfamiliar, that’s fine — screenshots of what you find are exactly what to send me.
I take the project from GitHub, run it locally against your Supabase project, and reproduce the failure. Lovable’s front end is usually the healthy part; the work is nearly always in the policies, the server-side logic and the boundaries between them.
Fixes go back through GitHub as small, reviewable commits, so Lovable stays in sync and you keep building in it afterwards. Nothing about the fix depends on me being around next month.
Yes — all of them, plus Claude, Copilot and ChatGPT output. I don’t much care which tool generated the code. What matters is the application underneath it: the architecture, APIs, database, dependencies, and where things are breaking. Lovable and Bolt projects tend to need deployment and backend work; Cursor and Copilot projects more often need the seams between generated pieces checked.
Usually not. Rewriting is the most expensive option and it’s rarely the one the code actually calls for. I’d rather find the specific things that are broken and fix those.
Yes, and it’s one of the most common reasons people get in touch. "It works locally" is almost always an environment, configuration or build problem rather than a code problem, and those are findable.
It depends on the work, so I don’t publish a price list. After a first look I quote a fixed price for the diagnosis, and any fix is scoped from the findings — so you know the cost before any work begins, and nothing changes partway through.
The service
The app half-works. You've described the bug to the AI six times, and each fix moves the problem somewhere else. At some point the loop stops being cheaper than reading the code.
A practical method for debugging AI-generated code when prompting has stopped helping: reproduce it, read the seams, check the assumptions, and fix the cause.
Read
8 min read
The eight security problems that recur in AI-generated apps, from missing ownership checks to leaked secrets — with a fix and a test for each one.
Read
10 min read
It might need an engineer.
If you’ve spent hours asking AI to fix the same problem and you’re going in circles, stop fighting the code. Send me what you’ve got — I’ll figure out what’s wrong and tell you what I’d do next.
No cleanup. No judgment. The messy version is usually the useful version.