Launch day is the worst time to discover what your AI tool skipped.
Most of the problems we get called in to fix would have been cheap to catch before launch and expensive to fix after. So here is the list we wish every founder ran through before they pressed deploy.
It is twenty checks across four areas. You can do most of them yourself in an afternoon. A few need a developer to confirm, and I have flagged those. None of them require you to read much code.
Work through it honestly. A check you are not sure about is a check that fails.
Security (the five that matter most)
Security is where AI tools cut the most corners, because none of it shows up in a demo.
-
No secrets in the code. Search your project for API keys, passwords, and tokens written directly into files. They belong in environment variables, not the source. This is the single most common serious problem we find, and it needs a developer to confirm properly.
-
Passwords are hashed, not stored. If your app has its own login, the passwords in your database should be unreadable scrambled strings. If you can see them as plain text, stop and fix this before anything else.
-
The server checks permissions, not just the screen. Hiding an admin button from normal users is not security. The server has to refuse the action too. Ask whoever can read the code: “if someone sends this request directly, does the server still check who they are?”
-
Inputs are validated on the server. Every form and every field that reaches your backend should be checked there, not only in the browser. Browser checks are for helpfulness. Server checks are for safety.
-
There is some rate limiting. Can someone hit your login or signup a thousand times a minute? Without a limit, that is how accounts get brute-forced and how your bills explode.
Performance (before the traffic, not after)
Slowness is invisible until it isn’t. These checks catch the problems that grow with your user count.
-
Pages load in under three seconds on a normal connection. Test on mobile data, not just your fast home wifi. Users leave slow pages.
-
The app still feels fine with realistic data. Ten test records prove nothing. Load a few thousand and see what drags. This is where AI-written database queries usually fall over.
-
Images are not enormous. A single 8MB hero image will sink your load time. Check that images are compressed and sized for the web.
-
You are not fetching the same thing over and over. A common AI pattern is asking the database for data inside a loop, so one page makes hundreds of queries. A developer can spot this quickly, and it is worth asking about.
-
There is a loading state, not a frozen screen. When something takes a moment, the user should see that it is working, not a blank page that looks broken.
Reliability and UX (what users actually feel)
An app that works only on the happy path feels broken the first time real life happens.
-
Errors show a helpful message, not a crash. Trigger a failure on purpose, like submitting a broken form, and check the user gets a clear message rather than a white screen or a wall of technical text.
-
Empty states make sense. What does a brand-new user see before they have created anything? An empty dashboard should guide them, not look like a bug.
-
The app works logged out. Open your key pages in a private browser window with no account. Anything that should be public should load, and anything private should redirect, not error.
-
It works on a phone. Not “it technically renders” but genuinely usable: buttons tappable, text readable, nothing cut off. Most of your users will be on mobile.
-
You can undo a bad deploy. If your next release breaks the site, do you have a way back? A rollback plan turns a disaster into a five-minute fix. If you do not have one, this is the thing to sort out first.
Legal and compliance (boring, and non-negotiable)
You do not need a lawyer for the basics, but you cannot skip them either.
-
Cookie consent actually works. Decline cookies on your own site and check that analytics and tracking scripts genuinely do not load. A banner that ignores the user’s choice is worse than none.
-
You can delete a user’s data. If someone asks you to remove everything you hold about them, you should be able to do it. Test it with a real account.
-
Your privacy policy matches reality. A template policy that describes data handling you do not actually do is its own problem. It should reflect what your app really collects and shares.
-
You are only collecting what you need. Every extra field you ask for is data you now have to protect and justify. If you cannot say why you need it, drop it.
-
Payment and personal data go over secure connections only. Your whole site should be on HTTPS, with no mixed insecure content. Most hosts handle this, but confirm it rather than assume it.
How to use this
Go down the list and mark each item pass, fail, or not sure. The “not sure” answers are the ones to chase, because uncertainty here usually means the check was never done.
If you fail a handful, you are in normal company. Almost every app we assess fails several of these at first. The point of the list is not to feel bad. It is to turn “I think it’s ready” into a specific set of things to fix before your users find them for you.
The security items are the ones I would never launch without. A slow page annoys people. An exposed password database can end the product.
Want a second pair of eyes before you ship? Get a free code review. We will run your app against this list and more, and tell you exactly what needs fixing before launch day.