The 7 problems I look for first in every Lovable app
These are the seven problems I check first when someone hands me an app built with Lovable, and the ones I find most often. Each section says what the problem is, what it can cost you, and how to check your own app in a few minutes. They apply just as much to Bolt, Replit and v0 apps.
By Max Zeshut, 26 October 2026.
1. Database rules that are off, or let everyone in
A Lovable app talks to its Supabase database straight from the browser, using a public key that every visitor can see. That's by design. What keeps one customer out of another customer's data is row level security (RLS): rules on each table saying who may read and change which rows.
What I usually find is a table or two with RLS switched off, or a policy that lets any signed-in user read everything. The second one is easy to miss, because the dashboard shows a policy and it looks protected.
Check yours: in Supabase, open the Security Advisor and the list of tables. Then make two accounts in your own app and see whether the second can find anything the first created. More on RLS.
2. Secret keys in the browser
When an AI builder wires up OpenAI, an email service or Stripe in a hurry, the secret key sometimes ends up in the frontend code, where anyone can copy it. The Supabase service role key, which ignores every database rule, is the worst one to find there.
Check yours: open your live site, then the browser's developer tools, and search the loaded files for sk_, sk-, service_role and secret. If you find one, rotate it at the provider first. More on exposed keys.
3. Payments the browser confirms
A checkout that unlocks access on the "payment successful" page can be unlocked by visiting that page. And when the redirect fails, a customer pays and gets nothing. Access should change only when Stripe's webhook arrives and its signature checks out, including when a subscription is cancelled or a payment fails.
Check yours: in Stripe, look at Developers, then Webhooks, in live mode. Is there an endpoint on your real domain, and are its recent deliveries succeeding? More on webhooks.
4. No backup anyone has restored
Most AI-built apps rely on whatever backups the database plan includes by default, and nobody has checked what that is. Meanwhile, the same tools that built the app can run a migration that drops a table in one step. Uploaded files are usually not covered by database backups at all.
Check yours: look up what your plan keeps and for how long, then ask when you last restored one, even to a test project. More on backups.
5. Sign-in links that go to the wrong place
After moving to your own domain, confirmation emails, magic links and password resets often still point at the preview address. The default email sender is also rate-limited, so some users never get the email at all.
Check yours: sign up with a fresh email on your live domain, and click every link in every email. Note where each one lands. More on auth emails.
6. Nobody hears when it breaks
Without error monitoring, you find out about crashes from customers, or not at all. Without an uptime check, the app can be down for a night before anyone notices. Both take under an hour to set up and cost little or nothing at this size.
Check yours: if the app threw an error right now, who would be told, and how?
7. No limits on what costs you money
Sign-up forms, contact forms and especially AI features can be called in a loop by a bot. If each call costs you an OpenAI request or an email, someone else gets to decide your bill.
Check yours: could one visitor submit your form, or call your AI feature, a thousand times in a minute? Do your providers have a spending cap set?
What to do with this
Fix what you can yourself; every check above is safe to do on your own app. Only ever test an app you own or have written permission to test.
If you'd rather have it done, a Launch Check is $299: I go through all of this and more within 48 hours, fix the three worst problems, and send you a written report. Or take the free scorecard first.