The Pre-Launch Security Checklist.

AI made building software fast. It did not make shipping it safe. The failure mode is consistent: an application works beautifully on the happy path, and the doors nobody demonstrated are standing open. Every item below exists because skipping it has cost somebody real money or real data.

Run in order. Item four matters most, because fixing before mapping produces confident, incorrect work.

1. 01Protect yourself, not just the appAn accurate privacy notice that says what you collect, where it lives, and who receives it. Written by someone who knows the answer, not copied from a template.
2. 02Review database grants and row-level security togetherRow-level security enabled with no policies is worse than none at all — it looks safe and reads like an open door. Test with an anonymous session and two separate real users.
3. 03Test the failure path, not just the happy pathWrong passwords, unknown-email resets, reused verification links, duplicate signups, expired tokens. Most incidents live in the branches nobody demoed.
4. 04Map trust boundaries before fixing anythingPublic routes, sensitive data, privileged components, irreversible actions — mapped first. Fixes applied before the map exists are guesses with good intentions.
5. 05Review against OWASP with evidence, not vibesEvery finding needs the exact file and line, the exploit path, the preconditions, the impact, and a test that proves or rejects it. A finding nobody can reproduce is not a finding.
6. 06Client-side validation is UX, not securityEvery untrusted request is validated again on the server, and authorization is checked as its own step. Hiding a button has never been an access control.
7. 07Hunt for data leaks in the places nobody looksClient bundles, API responses, logs, source maps, build artifacts. A key that ships to the browser is a public key, whatever the code comment says.
8. 08Publishable keys in the browser, secret keys on the serverIf a secret has ever touched a public repository, it is rotated immediately — not deleted in a later commit, rotated. Assume it was read.
9. 09Treat an unfamiliar repository as hostileBefore anything gets shell, network, or credential access: read the instructions, hooks, tool configuration, environment files, and package scripts. Published incidents of agents stepping outside their sandbox are the reason this check exists.
10. 10Rate limits, concurrency limits, and cost budgetsOn authentication, forms, state-changing routes, and anything that calls a paid API. The bill is an attack surface too — an unbounded agent loop is a denial of service with your card on file.
11. 11Patch known vulnerabilities, then prove the fixUpdate the framework, reproduce every finding, review every fix, test again, and scan again. A fix nobody re-tested is a change, not a repair.

How we use it

Nothing ships to a real user with a check unverified. Each item produces evidence — a request, a policy review, a test, a scan — and any item that cannot be evidenced is treated as a launch blocker rather than a note for later. "We'll fix it after launch" is how the incident gets scheduled.

If you are buying an AI-built application from anyone, these eleven questions are a fair thing to ask. The answers should arrive as evidence, not adjectives.

Living document. Revised as the tooling and the threat surface change; the date at the top moves with it.