Built it with AI? Test it before your customers do.
Sixteen tests you can run yourself on an app built with Lovable, Bolt, Replit, Cursor, Claude or anything else. You don't need to read any code. Each test says what a fail looks like, why AI tools tend to get it wrong, and gives you a prompt to paste back into your tool to fix it.
16 testsUnder an hourNo code readingFree, no sign-up
Before you start
Two browsers, or one normal window and one private window, so you can be two people at once.
Two test accounts in your app. Call them Alice and Bob.
Payments in test mode, if your app takes them. In Stripe, card 4242 4242 4242 4242 with any future date works.
Somewhere to note what failed. Tick each test below as it passes and this page remembers your progress.
Test data, not your real customers' details. If you do need to paste real data into your AI tool to fix something, strip the personal information out first. FormatTools does it free, in your browser.
Only run these tests on an app you own, or one you've been given permission to test. They catch the most common problems in apps built with AI tools. They aren't a full security audit.
Don't launch yet
If any of these fail, fix them first.
These are the problems that leak customers' data, give your product away free or run up a bill. They're also the ones AI tools most often get wrong, because the app looks fine on screen.
Test 01
The neighbour test
Can one customer see another customer's things?
How
As Alice, create something private: an order, a note, a booking, a document.
Open it and copy the page address.
In the other browser, sign in as Bob and paste that address.
Then, as Bob, open one of Bob's own items and change any number or code in the address by one.
A fail
Bob sees Alice's item, or anyone else's, even briefly.
Why AI misses it
The screen only shows you your own things, so it looks right. But the database underneath will often hand over any record to anyone who asks for it by number. Hiding something on screen isn't the same as protecting it.
Fix prompt
Check every page, API route and database query that reads or changes data. Make sure each one only returns records the signed-in user is allowed to see, and that this is enforced on the server or in the database's security rules (for example Supabase row-level security), not just hidden in the interface. List every table and route, and how each one is protected.
Test 02
The signed-out test
Do private pages stay private when nobody's signed in?
How
Signed in, copy the address of three private pages: an account page, a list of your data, and something inside it.
Open a fresh private window, where you're not signed in, and paste each one.
A fail
Any private content appears, even for a moment before it sends you to the sign-in page.
Why AI misses it
The check that sends you to the sign-in page often runs in the browser after the data has already loaded. A flash of data on screen means the data has already left the server.
Fix prompt
Make sure every private page and API route checks the user is signed in on the server before loading any data, and returns nothing or redirects if they aren't. Don't rely on a check that runs in the browser after the page has loaded.
Test 03
The key hunt
Has a secret password to one of your services been shipped to every visitor?
How
Open your app in Chrome, right-click and choose Inspect.
Press Ctrl+Shift+F (Cmd+Option+F on a Mac) to search every file the page loaded.
Search for each of these in turn: service_role, sk_live, sk-, sk-ant-, secret, private_key.
A fail
Any secret key turns up. Some keys are meant to be public and are fine: a Supabase "anon" or "publishable" key, and a Stripe key starting pk_.
Why AI misses it
Calling a service straight from the browser is the quickest way to make a feature work, so that's what AI tools often do. Anything in the browser can be read by anyone. A secret key there lets a stranger use your database, your payments or your AI account as if they were you.
Fix prompt
Find every secret API key used anywhere in the browser code. Move each one into server-side code or environment variables so it never reaches the browser, and change any feature that needs it to call our own server instead. Then tell me exactly which keys I need to cancel and replace in each provider's dashboard, because any key that has been in the browser should be treated as leaked.
Test 04
The open database test
Could someone skip your app and read your database directly?
How
Supabase: open your project's Table Editor and look for any table marked as unrestricted or with RLS (row-level security) off. Then open Advisors → Security Advisor and read every warning. Firebase: open your Firestore and Storage rules and look for allow read, write: if true, or rules left in "test mode".
A fail
Any table holding real data has no rules, or rules that let anyone in.
Why AI misses it
Tools like Lovable and Bolt connect your app to the database with a public key. That's safe only if every table has rules saying who can read and change what. Without them, anyone who copies the public key from your site can read or change every row, without ever touching your app.
Fix prompt
Turn on row-level security for every table in the database, and write policies so users can only read and change their own rows, plus anything that is genuinely public. Show me the policy for each table in plain English, and list any table you have left open and why.
Test 05
The free-unlock test
Can someone get what they'd pay for without paying?
How
As Alice, buy or subscribe in test mode. Note the address of the page you land on afterwards, often something like /success or /thank-you.
As Bob, who hasn't paid, go straight to that address.
Then start a payment as Bob and close the tab on the payment page before finishing.
Finally, cancel Alice's subscription in Stripe's test dashboard and check what she can still use.
A fail
Bob gets paid features without paying, or Alice keeps them after cancelling.
Why AI misses it
The quick way to build payments is to unlock things when the "thank you" page loads. The safe way is to unlock them only when Stripe itself confirms the payment, through a webhook: a message Stripe sends to your server. AI tools often build the quick way.
Fix prompt
Change payments so access is only granted or removed when our server receives a verified Stripe webhook (checking the webhook signature), never when the success page loads. Make the webhook safe to receive twice, and handle cancelled, failed and refunded payments as well as successful ones. Explain how I can test each case in Stripe's test mode.
Test 06
The back-office door
Are your admin pages locked, or just hidden?
How
As Bob, an ordinary user, type the addresses of your admin pages straight into the browser: try /admin, /dashboard/admin, /settings/users, or whatever yours use.
A fail
The page loads for Bob, even if the buttons on it don't seem to work.
Why AI misses it
Removing the "Admin" link from the menu makes it look protected. If the page itself doesn't check who's asking, anyone who guesses the address is in.
Fix prompt
Make every admin page and admin action check, on the server, that the signed-in user has the admin role, and refuse the request if not. Hiding links isn't enough. List each admin page and action and where the check happens.
Fix this month
These won't sink you on day one.
They'll hurt within weeks: a surprise bill, emails in spam, a change you can't undo, or a problem you only hear about from an annoyed customer.
Test 07
The bill-shock test
What stops one person running up your costs?
How
List every feature that costs you money each time it's used: AI replies, text messages, emails, image generation, maps. For each, ask: if one user, or a bot, used it 10,000 times tonight, what would stop them? Then check each provider's dashboard for a monthly spending cap.
A fail
Nothing limits how often it can be used, or there's no spending cap set.
Why AI misses it
Limits aren't part of making a feature work, so they're rarely added unless you ask. A free sign-up form plus an AI feature with no limit is an open tab on your card.
Fix prompt
Add sensible per-user and per-IP rate limits to every feature that calls a paid service (AI, SMS, email and so on), with a friendly message when someone hits the limit. Then list each paid provider we use and tell me where in its dashboard to set a monthly spending cap.
Test 08
The shared-link test
Are uploaded files as private as they should be?
How
As Alice, upload something private: an invoice, an ID photo, a document.
Right-click it, copy the file's own address, and open that in a private window.
Wait a day and try the address again.
A fail
A private file opens for anyone with the link, and the link never expires. That's fine for public images, such as profile pictures or product photos, but not for documents.
Why AI misses it
A public storage folder is the simplest thing that works, so private documents often end up in one.
Fix prompt
Move private uploads into a private storage bucket. Only let their owners (and admins) access them, using short-lived signed links, and keep only genuinely public images in a public bucket. Tell me which existing files need moving.
Test 09
The inbox test
Do your sign-up and password emails actually arrive?
How
Sign up, then reset your password, using a Gmail address and an Outlook or Hotmail one. Check where each email lands, who it's from, and whether the link works when you open the email on your phone but signed up on your laptop.
A fail
It lands in spam, arrives from an address that isn't yours, takes minutes to arrive, or the link breaks on another device.
Why AI misses it
Most app platforms come with a built-in email sender meant for testing. It's slow, limited to a handful of emails an hour, and sends from someone else's address. Real customers need email sent from your own domain, set up so inboxes trust it.
Fix prompt
Set the app up to send all emails (sign-up, password reset, receipts) through a proper email provider from our own domain instead of the platform's built-in test sender. Walk me through the DNS records (SPF, DKIM and DMARC) I need to add, and make sure every email link works when opened on a different device.
Test 10
The awkward-customer test
What happens when people type things you didn't expect?
How
In every text box, try: a name like Siobhán O'Neill, a few emoji, a very long paragraph (paste 2,000 characters), and <b>hello</b>. Then try saving a form twice by double-clicking the button.
A fail
The page breaks or overflows, an error appears, the word hello shows up in bold, or the double-click creates two of something.
Why AI misses it
AI tools test with tidy, made-up data. Real people have apostrophes in their names, paste in whole emails and double-click everything. Text that turns bold means the app is treating what people type as part of the page, which is how more serious attacks start.
Fix prompt
Check every form and every place user-entered text is shown. Make sure text is always displayed as plain text and never as HTML, that sensible length limits are checked on the server, that names with accents and apostrophes work, and that submit buttons can't create duplicates when clicked twice.
Test 11
The undo test
Could you get yesterday's working version back in five minutes?
How
Ask yourself: is the code saved in a repository such as GitHub, in your own account? Does each change the AI makes get saved as a separate step you could go back to? Then actually try it: restore yesterday's version in a copy.
A fail
The only way to undo a change is to ask the AI to put it back the way it was.
Why AI misses it
When you ask for one change, AI tools sometimes quietly rewrite parts you didn't mention. Without a saved history you won't know what changed, or be able to get the working version back.
Fix prompt
Make sure this project is connected to a Git repository in my own account, and that every change you make is saved as a separate commit with a plain-English message describing what changed. Explain how I can go back to an earlier version if something breaks.
Test 12
The 2am test
If something breaks overnight, who finds out first: you or a customer?
How
Visit a nonsense address on your site, such as /this-does-not-exist. Then turn your wifi off halfway through saving a form. Look at what a customer would see, and ask whether anything would have told you.
A fail
A blank page, a wall of technical error text, or silence: you'd only find out from an annoyed customer.
Why AI misses it
Things going wrong isn't part of the happy path an AI tool builds and tests. Error pages and alerts only get added when someone asks for them.
Fix prompt
Add friendly error and not-found pages, show a clear message when saving fails (without losing what the user typed), and set up error tracking so I get an alert when something breaks. Suggest a free or low-cost error-tracking service and walk me through connecting it.
Before you grow
These matter more with every new customer.
Who owns what, what happens to your data, and whether anyone but you and your AI tool could keep this running.
Test 13
The ownership test
If you fell out with your AI tool tomorrow, what would you still have?
How
For each of these, write down whose name it's in and whose card pays for it: the domain, the code, the database, the hosting, Stripe, the email sender, and any AI service the app uses. Then check you can download a full copy of the code and the data.
A fail
Anything only exists inside the app builder's account, or a freelancer's, or you can't export it.
Why AI misses it
App builders make starting easy by holding everything for you. That's fine for a prototype, but a business needs to own its code, its data and its customer relationships.
Fix prompt
List every external service this app depends on (hosting, database, payments, email, AI, domain, storage), where each one's settings live, and which environment variables it needs. Tell me what I would need to move each into accounts I own and run the app outside this tool.
Test 14
The bad-Monday test
If your data was deleted this morning, could you get it back?
How
Find out where your backups are, how often they're taken, and how far back they go. Then restore one into a copy of the app and check the data is really there. Also check your plan: some free database plans pause after a period without activity, and some don't include backups at all.
A fail
No backups, backups you've never tried restoring, or a free plan that could pause while customers depend on it.
Why AI misses it
Backups are a setting on your account, not a feature in your code, so the AI tool never sees them. Nobody discovers their backups don't work until the day they need them.
Fix prompt
Explain how this app's data is backed up today, how far back I can restore, and the exact steps to restore it. Tell me whether our current plans could pause or delete anything when they're inactive, and what I'd need to change before real customers rely on it.
Test 15
The leaving test
Can a customer take their data and go, and does your privacy policy tell the truth?
How
As Alice, try to download her data, then delete her account. Check it's really gone from the database, not just hidden. Then read your privacy policy against what the app actually collects, and every service it sends data to, including any AI provider.
A fail
Deleting an account needs you to do it by hand, the data stays in the database, or the privacy policy is a template that doesn't match the app.
Why AI misses it
Signing up gets built because it's needed to use the app. Leaving rarely does. In the UK and EU, people have a right to their data and to have it erased, and your privacy policy has to describe what you really do.
Fix prompt
Add a way for users to download their own data and to delete their account, which removes or anonymises their personal data everywhere it's stored, including uploads. Then list every piece of personal data the app collects and every outside service it's shared with, so I can check our privacy policy matches.
Test 16
The stranger test
Could someone new understand your app in an hour?
How
Imagine handing the app to a developer, or opening a brand-new AI session with no chat history. Is there a written guide in the project that says what the app does, how to run it, where the settings and secrets live, and what must never be changed without care?
A fail
Everything anyone knows about how it works lives in old chat history.
Why AI misses it
Each AI session starts fresh. Without a written guide, every new session, and every person you bring in, has to rediscover how things work, and is more likely to break something while doing it.
Fix prompt
Read through this whole project and write a README in plain English: what the app does, how it's structured, how to run it, every outside service it uses and where its settings live, and a short list of things that must not be changed without care. Also write a rules file for AI assistants working on this project, with the same warnings.
How to read your results
Any fail in tests 1–6
Don't launch yet, or if you've already launched, fix it this week. These are the ones that leak data or give your product away.
A few fails in 7–12
Normal for a first version. Fix them in order over the next month.
Fails in 13–16
Fine for a test with friends. Sort them before you rely on the app for income, or before you hire anyone to work on it.
Everything passes
Good. Run the list again after any big change, because AI tools can undo a fix while making the next one.
These tests catch the most common problems in apps built with AI tools. They aren't a full security audit or a penetration test, and passing them doesn't guarantee an app is secure. If your app handles health, financial or children's data, get it reviewed properly before launch.
Failed something? I'll fix it properly.
A fixed-price review of your app for £350: a written list of what's wrong, ranked by risk, with a fixed price to fix it. The £350 comes off the fix if you go ahead.