What breaks in Lovable apps
By Virgil Nilson, founder of Park23
Lovable is one of the fastest ways to go from an idea to a working product. Founders with no engineering background build things in a few weekends that would have taken a small team months. I mean that as a compliment.
But “working” in Lovable’s preview and working for a few hundred strangers on the internet are different things. When founders bring Lovable apps to us, we see the same handful of problems again and again. None of them are visible in a demo, which is exactly why they get missed.
Here’s what breaks, roughly in order of how much damage it can do.
1. Users can see each other’s data
Lovable apps store their data in Supabase (or Lovable Cloud, which runs on it). Supabase protects data with row-level security: rules on each table that say who can read and change which rows.
When those rules are missing or too loose, any signed-in user, and sometimes anyone at all, can read or edit records that belong to someone else. The app itself might never show it, but the data is reachable by anyone who opens their browser’s developer tools.
This is the most common serious problem we find, and it’s not just us. In 2025, a security researcher scanned a large number of public Lovable apps and found many of them exposing user data this way. Lovable has since added security scanning, which helps, but a scanner can tell you a rule is missing. It can’t tell you what your rules should be for your business.
How to check: open Supabase, go to each table, and confirm row-level security is on and that every policy matches who should really have access. If you see true as a policy condition, look closer.
2. Logins that only work in preview
Authentication often works perfectly in the preview, then breaks on your real domain. Google sign-in sends people back to the wrong address. Magic links expire or land on a blank page. Sessions end at random.
The more serious version: permissions checked only in the browser. If your app decides who is an admin by looking at something the browser sends, a curious user can change it.
How to check: sign up as a brand-new user on your live domain, on your phone, with an email you’ve never used. Then try every page an admin should see.
3. Stripe in demo mode
Checkout works once, so it looks done. But real payments need more: verified webhooks so nobody can fake a “payment succeeded” message, handling for failed and disputed payments, and a subscription status that stays in sync with what each user can actually use.
When that’s missing, you get users with access they didn’t pay for, or paying users locked out.
How to check: in Stripe, look at your webhook endpoint and recent deliveries. If there are failures, or no webhook at all, it’s not finished.
4. Secrets in the wrong place
AI apps call paid services, like OpenAI, Anthropic or image models. Those calls need API keys. When keys end up in browser code, or in Supabase Edge Functions that anyone can call without signing in, someone else can run up your bill.
How to check: search your project for anything that looks like a key. Any function that calls a paid API should require a signed-in user and have a limit on how often it can be called.
5. Uploads that fall over
Uploads look simple: a button, a progress bar. With real users they get hard fast. Large files, slow connections, phones that lock mid-upload, files that are still downloading from iCloud.
Video and photo apps hit this hardest: large batches of high-resolution files, uploaded from phones. The files often reach storage fine. It’s the steps after, processing and delivering them, that break. Fixing that means rebuilding the pipeline behind the button, not the button itself.
How to check: upload the biggest file a real user would, on your phone, on hotel Wi-Fi.
6. The fix loop
This one isn’t a bug, it’s a pattern. You ask Lovable to fix something. It does, and something else breaks. You ask it to fix that. Credits drain, and after a while nobody can say what the code actually does anymore.
It happens because there are no tests. Without them, neither you nor the AI can tell whether a change broke something until a user finds it.
What helps: stop adding features, and put tests around the few flows that make you money (sign up, pay, the core thing your product does). After that, changes stop being a gamble.
Should you leave Lovable?
Usually not. Most Lovable apps have a solid frontend and a weak backend. We keep the screens and flows that work, fix what’s underneath, and can keep the project compatible with Lovable so you can still make UI changes there. Some founders prefer to move to a normal codebase once a team is working on it. Either is fine. It depends on where the product is going.
If any of the checks above made you nervous, that’s what our Lovable rescue is for. A senior engineer goes through all of this and more in five business days, and tells you exactly what to fix first.