How to test an AI-built app before you share it

Updated 2026-08-27 · MateValidate

The app works — for you, on your machine, on the paths you always click. Now you are about to share it: with a client, on a launch post, with the group chat. Between those two moments there should be a testing pass, and this customer famously has no tester to do one.

Here it is. Eight checks, ordered so the cheapest and most brutal come first. Everything runs in a normal browser; nothing needs code.

1. Open it the way a stranger does

A private window, the deployed URL (not the editor preview, not localhost). No cached files, no logged-in session, no warm data. A remarkable share of "it works for me" dies right here — if the first paint is blank, you have a blank screen problem (or its Lovable variant), and nothing else on this list matters until it is fixed.

2. Open the console, and leave it open

Press F12 → Console, and keep it open for every remaining check. This is the single practice that separates people who find bugs from people who ship them: AI-built apps log their failures precisely where nobody is looking. A page can render perfectly while errors pile up under it. Every red line is a finding — the two most common families are Cannot read properties of undefined and Failed to fetch / CORS.

3. Press every control once

Not the happy path — every button, link, menu item and icon, on every page, once. You are not judging the features; you are asking one question per control: did anything happen, and was it the thing the label promises? Generated UIs ship controls wired to nothing — a Save that saves, next to an Export that has never once run. Write down every dead control; they are findings even when nothing crashes.

4. Feed the forms what real people type

On each form: submit it empty. Then with the wrong shape (letters in the phone field, not-an-email). Then with too much (paste a paragraph into Name). Then double-click the submit button — did it create two records? The app should refuse bad input with a readable message and survive rudeness without a console error. Optimistic generated code usually fails at least one of these.

5. Refresh everywhere, and share a deep link

On every main page: press refresh. Then paste one inner URL into the private window directly. If clicking works but refreshing 404s, that is a two-line hosting fix — and it is exactly the failure your launch-day visitors hit first, because they arrive by direct link.

6. Be the second user

Create a fresh account and look at the app with nothing in it. Two different findings hide here:

• The empty state: dashboards written against demo data crash or render nonsense the moment every list is truly empty.
• The leak: can this new account see, or open by URL, anything belonging to your first account? That check — one minute — is the most important on this page, and it fails often enough in generated apps to deserve its own security checklist, with the database policy fix behind most failures.

7. Shrink the window, slow the network

Drag the window to phone width — half your traffic arrives there. Menus that never open, buttons off-screen, text over text: all findings. Then, in DevTools → Network, set throttling to Slow 4G and reload: do loading states appear, or does the app flash a crash while data is still on the road? Slow networks are where not-loaded-yet bugs come out.

8. Send the errors to the thing that wrote the code

Everything you collected — console lines, dead controls, forms that accepted garbage — goes back to your AI verbatim. Not "the app is broken":

I tested my deployed app as a stranger would. Findings:

1. First console error on load: [paste exact text]
2. Dead controls: [list — page and label]
3. Forms accepting invalid input: [which form, what it accepted]
4. Refresh/deep-link behavior: [works / 404s on which routes]
5. Second account could see: [nothing / what exactly]

Fix these root-cause by root-cause — no try/catch wrappers or optional
chaining to silence errors, no hiding UI instead of fixing permissions.
After each fix, tell me the exact steps to verify it from the outside.

What a scanner adds to this

Steps 1–2 of this list — open every page cold, read every console error, catch every failed request and blank render — are mechanical, which means they can be done for you, on every page the crawler can reach, in about a minute. That is what the free scan does, and its report is written to be pasted straight into step 8. The manual checks are yours to keep: no scanner knows what your Save button is supposed to save.

Run the pass again after every big regeneration session. The AI does not remember what it broke last time — the checklist does.