Before real users: a checklist for AI‑built prototypes
Lovable, Bolt, v0, Replit and Cursor get you to a convincing demo fast. The gaps show up later, when strangers sign up and money moves. These are the checks we run first on any prototype. Most take five minutes, and you don't need to read much code to do them.
The nine checks
Can one user see another user's data?
The most common and most serious gap. A page that hides other people's records in the interface can still hand them out to anyone who asks the server directly.
Check: make two test accounts. Copy a link or record ID from one and open it while signed in as the other. If your app uses Supabase, make sure Row Level Security is switched on for every table that holds user data.
Are any secret keys in the browser or the repo?
Payment secret keys, database passwords and AI API keys belong on the server only. If they ship to the browser, anyone can copy them.
Check: search the repository for “sk_”, “secret” and “password”, and look for a committed .env file. Anything you find, move to the server and rotate the key.
Do payments survive the real world?
Test mode always works. Live mode adds failed cards, refunds, duplicate webhooks and customers who close the tab halfway.
Check: confirm orders are marked paid by a verified webhook, not by the page the customer lands on after paying. Run one real low-value payment and one refund before launch.
Is there a backup, and has anyone restored it?
A backup nobody has restored is a hope, not a backup. Also check that test data and real data live in separate databases.
Check: find where backups are configured, how often they run, and restore one into a scratch database.
Will you know when something breaks?
Without error tracking, the first sign of a bug is a customer who quietly leaves.
Check: trigger an error on purpose and see whether anyone gets told. If not, add error monitoring and an uptime check before launch.
Is there a ceiling on costs?
AI calls, image processing and emails are cheap per request and expensive in a loop. A busy day, or a bot, can run up a bill overnight.
Check: set spending limits with every provider, add rate limits to sign-up and any AI endpoint, and put a bot check on public forms.
Do your emails arrive?
Sign-up confirmations and password resets that land in spam feel exactly like a broken product.
Check: send from your own domain with SPF, DKIM and DMARC set up, and test with Gmail and Outlook addresses.
Can users leave, and do they know what you keep?
A privacy notice, a way to delete an account, and only the data you actually need. App stores, payment providers and privacy laws, including Hong Kong's Personal Data (Privacy) Ordinance, expect it.
Check: delete a test account and confirm its data is gone or anonymised.
Is everything in your name?
Domain, hosting, database, payment account, email sender, the code repository and the AI tool project itself. If any of these sit in a freelancer's or a friend's account, fix that first.
Check: list every service the app uses and who owns the login. Anything that isn't yours, transfer now, while it's easy.
Fix or rebuild?
Most prototypes are worth keeping: the screens and flows are real work. A rebuild makes sense when the data model fights every new feature, or when access control would have to be redone everywhere. Decide after the review, not before.