Rebuild · Lovable

Lovable in production: patch or rebuild?

Lovable got you live, and that mattered: roughly 8 million people use it (Panto, 2026), and your app is one of the ones that found real users. This page is for what comes next. It covers the failure modes that show up when a Lovable app meets production, the evidence behind them, and a ten-question self-assessment that answers honestly whether you need a patch or a rebuild.

Take the ten-question assessment → Or start with 20 minutes →
lovable app · production1 policy missing
the app still worksnobody notices until someone finds the hole
Sound familiar?

Their words, not mine.

If your version sounds like any of these, you’re in the right place:

  • Credits burn on fix loops: the same bug costs you three prompts, then five, then a support ticket.
  • A feature request quietly broke something that used to work, and you found out from a customer.
  • You suspect your Supabase tables are readable by people they shouldn’t be, and you don’t know how to check.
  • The app works, but you can’t answer a customer’s security questionnaire, and a deal is waiting on it.
  • You want the product off the platform, or at least want to know what leaving would cost.

“I spent over 12 hours giving detailed requirements, but every build came back broken or wrong. This wasted my credits and time. Now when I try to fix it, I’m blocked and told to pay more. This is unfair — I shouldn’t pay extra to correct work done wrong.”

Jason Lee, Lovable feedback forum, June 10, 2026

“A founder asks the AI to add a feature or fix an unrelated bug, and in the process it silently reopens something that was previously locked down: loosens a CORS policy that was intentionally restrictive, or regenerates a Supabase table without carrying over the RLS policies. None of these throw an error. The app still ‘works.’ Nobody notices until someone finds the hole.”

commenter “FixBrokenApp”, Indie Hackers audit thread, May 2026

“A 600,000-line TypeScript codebase built entirely by AI through Lovable by a solo non-technical founder in 6 months. The audit revealed passwords generated with Math.random() instead of crypto, database security policies left open, every API endpoint accepting requests from any website, and only 2 test files for the entire codebase.”

from “I review AI-built codebases for a living”, Indie Hackers, 2026
Why this happens

The pattern is documented, not anecdotal.

Lovable’s failure modes in production are a matter of public record, not opinion. Here is that record in order, with the disputes left in.

Lovable pairs a generated frontend with a Supabase backend. Supabase is well built: its public API key is designed to be exposed, and it is safe exactly as long as Row Level Security policies are configured on every table. The generator historically didn’t guarantee that, and a non-technical owner has no way to notice. That single gap explains most of the incident record.

The full evidence, with sources →
March 2025 · CVE-2025-48757

Missing Row Level Security, and a disputed CVE

CVE-2025-48757, filed after security researcher Matt Palmer’s findings in March 2025, describes insufficient Row Level Security in Lovable-generated sites, allowing unauthorized reads and writes; a follow-up scan found 170 of 1,645 tested apps exposed across 303 endpoints (Superblocks, 2025). Honesty requires the other half: the CVE is formally disputed by the vendor, NVD assigns it no score of its own, and the 8.26 severity figure comes from third parties. Lovable now applies RLS to newly generated schemas; apps generated earlier stay vulnerable until someone fixes them by hand (VibeAppScanner status review, 2026).

February–April 2026 · source code exposure

Reported, closed unescalated, fixed in two hours

Between February 3 and April 20, 2026, a backend regression made chat history and source code of public Lovable projects readable by other users; researchers reported it through HackerOne from February 22, and the reports were closed unescalated until a public disclosure forced a fix, which then took two hours. Lovable’s own post-mortem, published April 22, 2026, says it plainly: they “hadn’t built the product safeguards, the communication muscle, or the security processes to match the trust our users placed in us.” The full incident series, including where researcher and vendor accounts differ, is in the guide below.

Spring 2026 · Veracode GenAI report

The deeper mechanism isn’t one bug

Veracode’s Spring 2026 GenAI report measured AI-generated code passing security checks at roughly 55%, essentially unchanged in two years. Generators optimise for code that runs, not code that’s safe, and each regeneration can silently undo a previous fix. That’s why the dangerous question for a Lovable app in production isn’t “what’s broken?” but, as one auditor put it, “what used to be restricted that quietly isn’t anymore?”

Patch or rebuild

Ten questions. An honest answer.

Not every Lovable app in trouble needs a rebuild, and this assessment will tell you if yours doesn't. No email required; the result shows immediately.

01 Where does your traffic come from?

The Supabase database behind your Lovable project sits in one physical place, and every request your users make travels there and back. Customers near it get a short trip; customers on another continent wait longer for the same click, every single time.

For a Lovable app: if your users are global, you're bound to where your backend region sits, and that's fixed once set.

02 How big are the pieces of data you handle?

This is about what your users actually send and receive. A signup form, a comment or an order is a handful of text and numbers: tiny. A photo upload, a PDF or a video is thousands of times bigger. Databases are built for the small stuff; big files are supposed to live somewhere else and be linked to.

Large files belong in object storage; if they're going through your database path, that's fixable without a rebuild.

03 Does your data need to be queried later, or used once and dropped?

Some things you save because you will look them up again: customers, orders, saved projects. Other things pass through once and never matter again, like a webhook that fired, a log line, or the raw reply from an AI call you already showed the user. Both often end up in the same Supabase tables, but only the first kind has to stay there.

Process-and-discard data cluttering your tables is a cleanup, not a rebuild.

04 Is your app read-heavy or write-heavy?

Reading is looking something up; writing is saving or changing something. If most visits are people browsing a listing, opening a dashboard or checking a status, you are read-heavy. If your users are constantly creating and editing records, uploading, or your AI functions write rows on every action, you are write-heavy. Reads are easy to speed up; writes are the ones that queue.

Read-heavy Lovable apps often just need caching and better queries.

05 What genuinely needs to be real-time?

Real-time means the screen changes by itself because something happened elsewhere: a chat message arriving, a live order board, two people editing the same record at once. That is not the same as fast — a page that loads quickly when you click is just fast — and it costs more, because your app has to hold a live connection open for every user at the same time.

Live updates at scale are an architecture question, not a prompt away.

06 Is the wall a hard platform limit, or the shape of your queries?

Something has stopped you, and there are two very different reasons it can happen. A hard limit is a ceiling someone else set — a cap on rows, connections or function runtime that no amount of clever work gets you past. The shape of your queries is how your app asks Supabase for things: ask badly and the same data crawls back, ask well and it arrives instantly. If you have never opened your Supabase dashboard to see which queries are slow, it is almost certainly the second one.

This is the central question. Slow, unprofiled queries usually mean optimise in place. A hard cap means the platform is the ceiling.

07 Where does your business logic live?

Business logic is the rules that make your product yours: how a price is calculated, who is allowed to see what, what happens when an order comes in, what your AI feature does with a prompt. In a Lovable app those rules usually sit inside the generated code and its edge or AI functions. The alternative is a backend you run yourself, where the rules are code you could take with you tomorrow.

Logic locked into platform functions raises the cost of every future move. Data alone is cheap to lift; logic is the expensive part.

08 Is this internal glue or your product's backbone?

Some Lovable apps are built for the team: an admin panel, a form that feeds a spreadsheet, a dashboard three colleagues open. Others are the thing customers log into and pay for. Same technology, completely different stakes when it breaks at two in the morning.

A wobbly internal tool is an annoyance. A wobbly backbone is churn.

09 What's your compliance surface?

Compliance surface means how much trouble you are in if your data leaks. Names, emails, addresses and anything about a person fall under GDPR. Card details, bank data and health records raise it further. If your Supabase tables hold only your own content and no personal data, your exposure is genuinely low; if they hold customers, it is not.

If you hold regulated data, the RLS history above isn't background reading. It's your risk register.

10 Who owns verification?

Verification is whatever catches a mistake before your customers do. Automated tests that check the important flows still work, and monitoring that tells you when something breaks in production. Clicking through the app yourself after a change is not nothing, but it only covers what you thought to click, and a Lovable regeneration can quietly change a part you never opened.

With no verification layer, every regeneration is a gamble you can't see.

How to read your answers

Question 6 weighs heaviest: query-shape answers pull toward patch, hard-limit answers pull toward rebuild. Questions 7 and 9 are rebuild amplifiers; if your logic lives in the platform layer or you carry regulated data, a hard limit anywhere gets more expensive to live with. The rest set the size and urgency.

The rebuild

Keep what you proved. Replace what caps you.

How the work runs → The engagement and pricing →
01

What stays

The product and the experience. Your users chose the flows, screens and logic you already validated; the rebuild treats them as the spec, not as debris.

02

What changes

The foundation. A stack chosen for your load, real auth and data boundaries with policies designed rather than generated, tests and monitoring between every change and production, and infrastructure you own end to end. Your data comes out of the platform; your logic comes out of AI functions and into code anyone senior can read.

03

What comes back is more than what broke

Because the work spans product, business, design and tech in one head, the rebuild is also where positioning gets sharpened and the design gets a senior pass. You’ll measure the result in your own numbers: fewer support tickets per customer, security questionnaires you can answer the same day, faster shipping, and a codebase a due diligence process can walk through. That’s the difference between a rebuild and a rebirth.

Who's behind this

Henrik Hallengren — 20+ years across product, tech, strategy and design; brands from Google to Mondelēz, worked with across roles and projects; production systems like the multi-tenant AI platform autoply built solo and running today. Independent: no platform ties, no referral fees.

The systems →About Henrik →
Next step

Start with the diagnosis.

Diagnosis: €7,500, fixed. One week. A written architecture and code review of your Lovable app: what’s exposed, what’s salvageable, what a rebuild costs. Useful even if you stop there.

Book a 20-minute call

Guides for Lovable