A Pre-Launch QA Checklist for Apps Built with AI Coding Tools

• —Every main journey works from a fresh account, end to end, including sign-up, the main action and sign-out.
• —Forms validate sensibly and show helpful errors; nothing is lost when validation fails.
• —Empty states, loading states and error states exist and make sense.
• —Repeated actions (double-click, back button, refresh mid-action) do not duplicate or corrupt data.

This is the area where the cost of a miss is highest. Create two ordinary accounts and try to reach one's data from the other: change the identifier in the address, call the underlying request directly, try an action that should need a different role. Also check what a signed-out visitor can see.

• —Account A cannot read, change or delete account B's records, by any route.
• —Roles (admin, member, guest) are enforced on the server, not just hidden in the interface.
• —Signed-out visitors cannot reach pages or data that need an account.
• —Sessions expire, sign-out really signs out, and password reset links cannot be reused.

• —Text fields cope with very long values, special characters, emoji and markup without breaking the page.
• —File uploads check type and size and do not trust the file name.
• —Search and filter inputs behave sensibly with unusual values.
• —Numbers, dates and currencies are validated, including negative and zero values.

A quick search of the repository and the built client code is a good first look. It will not find everything, but it finds the obvious ones.

# A rough first look for secrets that ended up in the repositorygit grep -nEi "(api[_-]?key|secret|token|password)\s*[:=]" -- . ':!*.lock' ':!node_modules'

• —No private keys or tokens appear in client-side code, the repository or its history.
• —Debug modes, test accounts and sample data are off or removed in the live environment.
• —Environment settings differ deliberately between test and live, and the live ones are the ones you tested.
• —Third-party services (payments, email) are on live settings only when intended, and in test mode otherwise.

• —Database rules and access policies match the access you intended; nothing is open by default.
• —The app stores only the data it needs, and you know where it is stored.
• —Deleting an account or a record does what it says.
• —Backups or exports exist for anything you could not recreate.

Generated projects often pull in packages nobody chose on purpose. List what is installed, remove what is unused, and look at anything unfamiliar or long out of date.

• —The app behaves sensibly on a slow or dropped connection.
• —The main flows work on the browsers and phones your audience actually uses.
• —The app can be used with a keyboard, text is readable and form fields have labels.
• —Errors are logged somewhere you will see them after launch.

Sort findings into three groups: blockers (data exposure, broken core flows, anything involving payments or personal data), fix soon, and accept for now with a note. The point of the exercise is not zero findings; it is knowing what you are shipping and having chosen it.

It is also worth being clear about what this kind of checking is. QA-level testing finds a lot, but it is not a penetration test, a code audit or a security certification, and it should not be described as one.