Lovable rescue

Lovable shipped fast. We fix what's actually broken underneath.

Lovable turns a prompt into a working Supabase-backed app in an afternoon, and that speed is real — we're not here to argue otherwise. What we get called in for is what the speed skips: row-level security left off by default, an auth check the model wrote backwards, a quick fix that patches one bug and opens a second one nobody's found yet. We take the app apart, find what's actually wrong under the polish, and hand back something a senior engineer can maintain. Not a rebuild from zero.

Send us the repo Read the FAQ

Founder

“Supabase tables are readable by anyone with the anon key.”

Auditor

“The login screen blocks real users and lets everyone else in.”

Engineer

“A stranger opened your project's source code and DB credentials.”

Investor

“Every 'fix' costs credits and might make it worse.”

Co-founder

“One small prompt rewrote three components you didn't touch.”

Hire

“Nobody on the team can explain why an RLS policy exists, or if it works.”

If you see this, this is you

The signals.
What they actually mean.

“Supabase tables are readable by anyone with the anon key.”

Security researchers scanned 1,645 live Lovable apps and found 170 of them, 10.3 percent, had row-level security off entirely. CVE-2025-48757. Emails, addresses, API keys, all exposed.

“The login screen blocks real users and lets everyone else in.”

A February 2026 incident on a Lovable-built exam app had the auth check backwards. Legitimate students got locked out. Unauthenticated requests got through. 18,000-plus users exposed, 870 records with full PII.

“A stranger opened your project's source code and DB credentials.”

April 2026: Lovable's own API had no ownership check on project data. Any free account could pull another user's source, database credentials, and AI chat history. That one wasn't your bug. It was theirs.

“Every 'fix' costs credits and might make it worse.”

Lovable's own FAQ caps free error fixes at ten before they start billing like any other message. That number exists because a fix attempt routinely doesn't land the first time.

“One small prompt rewrote three components you didn't touch.”

Ask it to move a sidebar, the mobile layout breaks somewhere else. One reviewer called iterating on Lovable 'less like engineering and more like gambling.' Lovable added targeted diff edits in August 2026, specifically to cut down on this.

“Nobody on the team can explain why an RLS policy exists, or if it works.”

One engineer watching this pattern on Hacker News put it plainly: AI-generated access rules look like 'pretty please' to anyone actually reading them. Present, but not enforced the way everyone assumed.

Our process

Five steps. 14 days.

012 days

Audit

We clone the repo and check row-level security on every Supabase table, not just the ones your team remembers creating. We diff the preview environment against production, and we check git history for the fingerprints of a full-file rewrite — usually a diff three times larger than the prompt that caused it.

021 day

Triage

Keep, rewrite, delete. For Lovable apps it's usually closer to 55/35/10 — the UI holds up, the data layer and auth logic don't.

035–8 days

Foundation

RLS turned on table by table, with each policy actually tested against a logged-out request, not just switched on and trusted. Auth logic rewritten in the direction it should have run. Every free-fix credit-burn cycle that patched a symptom gets replaced with a real fix at the cause.

042–3 days

Migration

Production users move to the corrected stack one at a time. Old and new run in parallel for 72 hours before we cut the old one off.

051 day

Handoff

Documented, tested, CI green. You can keep building in Lovable afterward — we just don't let it own the security boundary anymore.

What we do with the code

Three piles. Honest splits.

Keep

55%

UI, layout, brand, anything that doesn't touch auth or the database directly.

Rewrite

35%

RLS policies, the auth check, anything multi-tenant or touching Supabase directly.

Delete

10%

Dead routes, duplicate auth attempts from earlier fix-loop cycles, unused API keys still sitting in the client bundle.

Verdict

Who this is for.

Lovable crossed $100M in ARR eight months after launch and raised at a $6.6B valuation in December 2025. Millions of people are shipping real products with it. We're not telling founders to stop using it — we use tools like it too, for the parts of a build where speed matters more than architecture. What we are telling you is that the tool ships fast and doesn't check its own work in the places that actually hurt you: access control, auth direction, and what happens to a fix on the second and third attempt. Three separate publicly documented Lovable security incidents landed in the last thirteen months, and the most serious one, the April 2026 API bug, wasn't even in code Lovable generated for a customer. It was in Lovable's own backend. If your app is a landing page or an internal dashboard with no real user data behind it, you probably don't need us. If it has paying customers, PII, or anything behind a login, get the RLS and auth logic checked before it becomes someone else's headline.

FAQ

Questions founders ask.

Is this Lovable's fault or my fault?

Some of both, and it depends which bug. RLS being off by default was Lovable's design choice until they changed it — CVE-2025-48757 says so directly. The April 2026 bug where strangers could read your project data was entirely Lovable's backend, nothing you configured caused it. We tell you which is which in the audit.

Do you rebuild the whole app?

No. Roughly 55 percent of a typical Lovable app stays as-is — UI, layout, brand. We rewrite the auth and data-access layer, which is where the real defects live.

Can I keep using Lovable after the rescue?

Yes. We don't take Lovable away from you. We take away the parts where it was making security decisions it shouldn't have been trusted to make alone.

How do you know if my RLS is actually broken, not just theoretically risky?

We test every policy against a logged-out, unauthenticated request. If that request can read or write data it shouldn't touch, the policy is broken, not theoretical.

What if my Lovable app doesn't use Supabase?

Less common, but it happens. The audit still covers auth logic, credential exposure, and API-level access control regardless of which database you're on.

Ask anything