AI app builders like Lovable, Bolt, Replit, and v0 have changed what one person can make. Describe an intake form, a booking board, or a customer portal, and a working version is on screen the same afternoon. That's genuinely useful: a prototype you can click through explains what you want better than a page of notes.
The gap is between "it works when I try it" and "it's safe to let customers sign in." The builder gets you a long way toward the first. The second depends on a handful of things that don't show on screen. None of them need a computer science degree to check, and most you can look at yourself in an hour.
1. Sign-in, and who can see what
Most small-business apps hold something private: a customer's address, an order, a pet's vaccination record, a signed form. The first question is whether the app keeps each person to their own.
- Try it signed out. Open a private browser window, paste in the address of a page you normally see when signed in, and see what loads. You should get a sign-in screen, not the page.
- Try it as someone else. Make two test accounts. Signed in as the first, open one of the second account's records. If the address bar shows a record number, change it. You should see nothing that isn't yours.
- Check the admin pages. If staff or owner pages are only hidden from the menu, anyone who guesses the address can open them. The app has to check who you are before it shows them, every time.
2. Database access rules
Many AI-built apps talk to their database straight from the browser. Apps built with Lovable and Bolt often use Supabase for this. That's a normal design, but it's only safe when the database has its own rules about which rows each signed-in person can read and change. In Supabase these are called row-level security policies.
Without them, the app's screens may look private while the data underneath isn't. The key the app uses to reach the database is visible in the browser by design, so the rules are what stand between your customers' records and anyone curious.
Check: open your database dashboard and look at each table. Row-level security should be turned on for every table that holds customer or business data, and each one should have rules that match how the app is meant to work, such as "a customer sees only their own orders."
This isn't a far-fetched worry. A May 2025 study of 1,645 apps made with Lovable found 170 that let anyone read personal information, as The Next Web reported. In February 2026, The Register reported a security researcher's finding that an app hosted on Lovable and featured on its showcase page exposed the records of about 18,700 users: its sign-in check was backwards, letting strangers in and keeping signed-in users out. Lovable said every project gets a free security scan before it's published, and that acting on the results is up to the app's owner. That's the point: the builder can flag a problem, but someone has to read the warnings and fix them.
3. Secrets in the code
Apps connect to other services with keys: one for taking payments, one for sending email, one for an AI service. The rule is simple. Anything that runs in the browser is public. A key that can spend money or read data has to live on the server, in the hosting settings, never in the code that loads on the page.
Check: ask the builder, or someone who reads code, to list every key the app uses and where each one is stored. Watch for anything labeled "secret" or "service role" in the front-end code. If a secret key was ever in the code or the project's history, make a new one with that service and delete the old one. Removing it from the current code isn't enough, because old versions keep it.
4. Backups
The builder's version history covers your code. It usually doesn't cover the records your customers typed in. Those live in the database, and whether they're backed up, how often, and for how long often depends on the plan you're paying for.
Check: find the backup settings for your database and read what your plan includes. Then do the step almost everyone skips: try a restore, even into a copy. A backup nobody has restored is a hope, not a backup. And make sure you can export all your data in a format you could open somewhere else.
5. Where it's hosted, and what it costs to run
An AI-built app is often several services at once: the builder's subscription, hosting, the database, email sending, AI usage, and the domain. Some are flat monthly fees; others charge by use and can climb as the app gets busy.
Check: write down every service the app depends on, what it costs each month, and whose name and card the account is in. Then ask two questions. If you cancel the builder's subscription, does the app keep running? And can you get the code out? Most builders let you export the code or sync it to GitHub, so make sure yours is in an account you control, not only inside the builder.
6. Who can fix it
Sooner or later something breaks, often on a busy Saturday. Asking the AI to fix its own bug works some of the time; other times each fix breaks something else. Before customers rely on the app, know who you'll call.
Check: is there someone who can read the code and knows how the app is put together? Is there a short written note on how it works, where it's hosted, and how to get in? If the honest answer is "only the chat history," that's the gap to close first.
A one-page self-check
- In a private window, no customer data loads without signing in.
- Two test accounts can't see each other's records.
- Every table with real data has row-level security on, with rules that match the app.
- No secret keys in the front-end code, and any key that was ever exposed has been replaced.
- Database backups are on, and one restore has been tried.
- Every service the app uses is listed with its monthly cost and whose name it's in.
- The code is exported to an account you control.
- A named person can fix it, and a short note says how it works.
If every line is a yes, you're in better shape than most first versions. If several are "I'm not sure," that's normal, and it's fixable.
Where this leads: if you'd rather have someone go through it with you, our AI-Built App Check ($250–$500) reviews what you give us access to and gives you a written keep, fix, or rebuild verdict covering sign-in and who can see what, database access rules, secrets in the code, backups, hosting, and running costs. It's a review, not a penetration test, and up to $60 of the fee is credited toward your first three months if you go ahead within 60 days. If the verdict is "finish it," that's a Software add-on that starts from your prototype instead of a blank page; more on our custom software page.