Guide · AI-built apps
Is your Lovable or Bolt app safe to launch?
Apps built with Lovable, Bolt, v0 or Cursor often look finished long before they're safe to put in front of customers. These are the 12 things I check first, with the problems I found in two sample apps. Most take a few minutes to check, and some need no code at all.
By Kevin McCalley · Published 25 October 2026
Why "it works" isn't the same as "it's ready"
AI app builders build what you ask for, and nobody asks for "and make sure strangers can't read the database". In 2025 a security researcher scanned 1,645 apps from Lovable's public showcase and found 170 whose data anyone could read, because the database's access rules (Supabase row-level security) were off or set up wrong. It was logged as CVE-2025-48757. Lovable disputes the CVE, saying each app's database settings are the app owner's responsibility, which is exactly the point: they're yours to check.
The examples below come from two sample apps I built the way AI builders often leave them, then fixed: Classly, a class-booking app, and Crumbwell, a bakery checkout. Every problem and number is real, measured before and after.
Security: checks 1 to 6
The database only shows people their own data
If your app uses Supabase or Firebase, every table needs access rules turned on, with a rule for who can read and write each row. How to check: in Supabase, open Authentication → Policies; any table marked "RLS disabled" is readable by anyone who has your app's public key, and every visitor has it.
No secret keys in the browser
Payment, email and database admin keys must live on the server only. In Classly, the payments secret was bundled into the public JavaScript and printed to the browser console on every booking. How to check: open your live app, press F12, and search the Sources tab for secret, sk_ and service_role.
Permissions are checked on the server
Hiding the admin button isn't protection. Classly showed its admin screen only to the owner's email, but the check ran in the visitor's browser and the data behind it had no check at all, so anyone could read every booking. The server has to check who's asking on every request.
The server sets the price
Crumbwell's checkout sent its own total to the server, and the server believed it. Editing one number bought the €42 cake for €0.01, and the order went through. The server should price every order from its own product list and ignore any total the browser sends.
Links can't be guessed
Crumbwell's order pages lived at addresses like /order/1042. Changing the number to 1041 showed another customer's name, phone number and order. Anything private needs a long random link, a login check, or both.
Passwords and logins are handled properly
Classly stored passwords in plain text and served them from a public address, kept the whole user record in the browser's local storage, and treated a failed login as logged in. Passwords should be hashed, and sessions belong in secure cookies that page scripts can't read.
People: checks 7 to 9
It works on a phone
Classly told phones it was 1,200 pixels wide, so its 12px text showed at about 4px. On Crumbwell's checkout, a fixed cart bar covered the Place order button on phones. How to check: do your main task start to finish on your own phone, not in a desktop browser window.
It works with a keyboard and a screen reader
Put your mouse away and press Tab through sign-up and checkout. Can you reach and use every control? Classly had 23 WCAG issues and Crumbwell 30, mostly clickable boxes a keyboard can't reach and form fields with no labels. In Europe, the European Accessibility Act makes this a legal requirement for many shops.
Text is readable
Light grey on white is the most common failure. Normal text needs a contrast ratio of at least 4.5:1 against its background. Crumbwell's order button was 2.1:1. Free tools such as Chrome's Lighthouse report every failing colour.
Speed and reliability: checks 10 to 12
It's fast on a phone
Run Lighthouse in mobile mode (Chrome, F12, Lighthouse tab). Full-size camera photos are the usual cause of slow pages: Classly weighed 6.6 MB and took 25.6 seconds to show its main content on a phone. After resizing images and dropping unused libraries, it was 156 KB and 2.5 seconds.
Errors are visible
Turn off your Wi-Fi and use the app. If a list just stays empty, with no message and no way to try again, people assume it's broken and leave. Every loading step needs a loading state, an error message and a retry.
Dates, times and money are right
Crumbwell built its pickup slots in UTC, not Lisbon time, so for half the year it offered pickups after the bakery had closed. Check time zones, both clock changes, currencies and rounding with real examples.
If you'd rather have it checked for you
Within 48 hours you get a written review of your app against these checks and more, worst problems first, with a fixed-price plan to fix them. If you go ahead within 30 days, the €450 is credited to the fix. No call needed.
Questions
Is Lovable secure?
The platform itself is generally fine. The risk is in how each app's database rules and server checks are set up, and that part is the app owner's job. Lovable added a security scan, but early versions checked that access rules existed, not that they worked, so test them yourself.
Can I fix these myself?
Often, yes. You can ask the builder to turn on row-level security, move a key to the server or price orders on the server. Then check again in a private browser window, because a fix that was described isn't always a fix that was made.
Will fixing these change how my app looks?
No. In both teardowns the design stayed the same. The fixes were in the database rules, the server and the page code.
Which builders does this apply to?
All of them: Lovable, Bolt, v0, Cursor, Replit and hand-written apps too. The same mistakes show up wherever an app goes from idea to live quickly.
More guides
The European Accessibility Act for small online shops · Section 508 and accessibility reports for small software vendors