How to test an AI-built app before launch
The app works when you click through it. That is not a test. Here are the five things AI builders reliably get wrong, and how to check each one without writing code.
Your app works. You clicked every button, the pages load, the data saves. That is a demo, not a test, and the gap between them is where launches go wrong. Knowing how to test an AI-built app before launch comes down to deliberately doing the things you did not do while building: acting like a second user, entering wrong data on purpose, and checking that the parts you never look at behave when nobody is watching.
Two hours, five checks, no code required. Do them in this order, because the first one finds the most serious problems.
Why test an AI-built app before launch at all?
Because you built it in the one configuration where everything works: your account, your data, your device, your connection, and inputs you already knew were valid. Every check below is a deliberate departure from one of those five assumptions. That is all testing is at this stage, and it is why it can be done in an afternoon by someone who does not write code.
Check 1: be a different user
You built and tested the app as one person, logged in as yourself, with your own data. Almost every serious defect in an AI-built app hides behind that fact.
Create a second account. Then, logged in as user two, try to reach user one's data. Not by hacking, just by trying:
Copy a URL that contains an ID from account one. Paste it into a browser logged in as account two. Do you see the record?
Change a number in a URL. If /orders/41 is yours, what does /orders/40 show?
Open a page you should not have permission for, by typing its address directly rather than clicking a link.
Log out entirely and paste the same URLs again.
If any of those show data that is not yours, stop and fix it before doing anything else. This is the single most common failure in generated applications, because a builder asked for a page that shows an order will produce a page that shows an order, and enforcing who may see it is a separate instruction that nobody gave. It has topped the OWASP Top 10 as broken access control for years, and generated apps reproduce it faithfully. If you added login in the usual way described in how to add user accounts to an AI-built app, the sign-in screen exists. That is not the same as the data being protected.
Check 2: break every form on purpose
You have only ever entered correct data, because you knew what the form wanted. Your users will not.
Input | What to type | What should happen |
|---|---|---|
Empty required field | Nothing, then submit | A clear message next to the field, no crash, nothing lost |
Very long text | Paste 5,000 characters into a name field | Either a limit with a message, or it saves and displays without breaking the layout |
Wrong type | Letters in a phone or price field | Rejected with an explanation, not saved as zero |
Negative or zero quantity | -1 and 0 | Rejected. A negative quantity in a cart is a refund you did not intend |
Odd characters | O'Brien, an emoji, an apostrophe in an address | Saved and displayed correctly, no error page |
Double submit | Click submit twice fast | One record created, not two |
The double-submit row catches more real problems than the rest combined. Generated forms rarely disable the button while a request is in flight, which produces duplicate orders, duplicate charges and duplicate emails on any connection slower than yours.
Check 3: empty and overflowing states
You tested with three items in the list. Your app has two other states, and you have probably seen neither.
Empty. Delete everything and look at each page. A brand new user sees this view first, and a blank rectangle with no explanation is the most common reason people never come back. Every list needs a sentence saying what should be there and how to add the first one.
Full. Add two hundred rows. Does the page still load in reasonable time, does the layout hold, is there pagination or does it try to render all of them? Long lists are where an app first feels slow.
Speed is worth a separate look if anything crawls, and the usual causes are covered in why your AI-built app is slow. At this stage you are only looking for something obviously wrong, like a list taking eight seconds.
Check 4: money and dates, one row at a time
If your app touches payments or scheduling, this check is not optional and it is done by hand with a calculator.
For money: run one real transaction end to end, with a real card if the platform is live, for an odd amount like 7.13. Then check every place that number appears: the confirmation screen, the email, the database record, the provider's dashboard. Look for rounding drift and for the wrong currency being assumed. Generated code frequently stores amounts as floating point, which is fine until a total is out by a cent and a customer notices before you do. Anyone wiring this up should read how to add payments to an AI-built app for the parts that must be server-side.
For dates: create something scheduled for tomorrow and check what time it says on a device set to a different timezone. Booking apps built quickly are usually written as if everyone is in the builder's timezone, and the bug is invisible until the first customer in another country books a 9am slot that shows up as 3am.
Check 5: the things that only happen when you are not looking
Four small tests that cover the rest of the surface:
Email.
Trigger every automated message: signup, reset, receipt, notification. Check it arrives, check it is not in spam, and check the links inside it point at your real domain rather than localhost.
Refresh mid-flow.
Halfway through a multi-step process, press F5. You should land somewhere sensible, not on an error.
Back button.
Complete an action, then press back. You should not be able to submit the same thing twice by doing so.
Phone.
Open the app on an actual phone, not a resized browser window. Check that buttons are reachable with a thumb and that no field is hidden behind the keyboard.
Write down what you found, then fix in order
Keep one list with three columns: what you did, what happened, what should have happened. That format matters, because it is exactly what an AI coding agent needs to fix the problem, as described in how to write a bug report for an AI coding agent. Vague reports produce confident wrong fixes.
Fix in this order: data visible to the wrong person, money wrong, data lost, then everything else. The first two are the ones you cannot apologise your way out of.
What this pass does not cover
This is a launch check, not a security audit and not load testing. It will not find a subtle permission bug three screens deep, it will not tell you what happens at a thousand concurrent users, and it does not replace a real review of the code if the app handles anything sensitive. What it does is catch the failures that are both common and embarrassing, which is the right target the week before launch.
After launch the job changes shape: you are watching real usage rather than probing it, and the useful preparation is knowing what to do when your AI-built app breaks in production before it happens. Testing is the last step of building, and the first step of how to build an app with AI that anyone else relies on.
FAQ
Do I need to write automated tests for an AI-built app?
Not before launch, and not if you are not a developer. Manual passes catch the common failures. Automated tests earn their place once the app has users and you are changing it regularly.
How long should this take?
About two hours for a small app. The permission check is twenty minutes of that and finds the worst problems, so do it even if you skip everything else.
Can I ask the AI builder to test the app for itself?
It can generate test cases, which is useful. It is a poor judge of whether its own output is correct, and it cannot tell you that an empty state is confusing or that a flow feels wrong. Use it to widen coverage, not to sign off.
What is the single most common bug in AI-built apps?
Missing authorisation. The login screen works, but any logged-in user can reach any record by changing a value in the URL, because access rules were never specified.
Should I test with real customer data?
No. Use invented data that looks realistic. Testing with real personal data spreads it into logs, emails and screenshots you did not plan for.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
