A prototype only has to work for you, on your laptop, with your test account. A launched app has to work for strangers who will click things in the wrong order, share links, refresh during payment and occasionally try to get at data that is not theirs. Most of the gap between the two is not the visible app. It is the rules underneath it.
None of the checks below need you to read much code. Several you can do yourself in an afternoon. The rest are a good scope for a short paid review.
1. Can one user read another user’s data?
This is the big one. Tools like Lovable and Bolt usually pair the app with Supabase, where the browser talks to the database directly using a public key. That is fine by design, but only if Row Level Security is switched on for every table and each table has policies saying who can see and change which rows. Without them, anyone with the public key can query the table.
Open the Supabase dashboard and look at each table. If any table holding user data shows RLS as disabled, or has a policy that allows everything, stop and fix that before anything else. Then test it properly: sign up as two different users and try to load the second user’s records while logged in as the first.
This is not hypothetical. Security researchers scanning publicly listed AI-built apps in 2025 found a meaningful share with tables readable using only the public key (tracked as CVE-2025-48757). New tables added later by the builder can miss policies too, so re-check after every big change.
2. Are any secret keys in the browser?
Public keys are meant to be public. Secret keys are not: the Supabase service_role key, a Stripe secret key starting with sk_, an OpenAI or Anthropic API key, an email provider key. If one of these is in your front-end code, anyone can open the browser’s developer tools and copy it.
Search your project for those prefixes. Secrets belong in server-side functions or environment variables that never ship to the browser. If one has ever been in front-end code or a public repository, assume it is compromised: rotate it, then move it.
3. Does sign-up and login hold up?
- Can someone sign up with an email they do not own and get straight in? Turn on email confirmation if the app needs it.
- Does password reset actually send, and does the link expire?
- Can a logged-out visitor reach app pages by typing the URL directly?
- Are admin screens protected by a real role check, or just hidden from the menu?
4. Is the payment confirmed by the server?
If your app takes payment, the thing that unlocks a plan or marks an order paid should be a message from the payment provider to your server, not the browser landing on a “thank you” page. Anyone can visit a thank-you URL. We cover how this goes wrong in our Stripe webhook article.
5. What happens when something fails?
Turn off your Wi-Fi halfway through a form. Submit twice quickly. Upload a huge file. Generated apps often swallow errors silently, so the user sees a spinner forever and you never hear about it. At minimum, failures should show the user a clear message, and you should get an alert. A free tier of an error-monitoring service such as Sentry is enough to start.
6. Who owns the accounts?
List every service the app depends on: the builder, the database, hosting, domain, email, payments, any AI API. Check each is in the business’s name, on a business email, with billing you control and two-factor authentication turned on. Personal free-tier accounts are fine for a prototype and a real risk for a product.
7. Is there a backup, and has it ever been restored?
Find out whether your database plan includes backups, how often, and how long they are kept. Then do the part most people skip: restore one into a separate project and check the data is there. A backup you have never restored is a hope, not a backup.
8. Will the free tier survive launch day?
Free plans pause inactive projects, cap database size, limit emails per hour and throttle API calls. Read the limits for each service and estimate what a busy week looks like. The fix is usually cheap, but it is much calmer to upgrade before launch than during it.
9. Could someone else pick this up?
If the original builder, human or AI, disappeared tomorrow, could a developer work out how it fits together? A short README covering how to run the app, where the secrets live and how to deploy is worth more than any amount of clever code. If the business rules only exist inside a chat history with the AI tool, write them down.
If you only do three
Check database access rules, move secret keys server-side, and make payments server-confirmed. Those three cover most of the serious risk. The rest is about making problems visible and recoverable.
If you would rather have someone else run the checks, our AI app rescue starts with a fixed-price review. Paid diagnostic from $350. Most rescue fixes land between $500 and $4,000.
