Before you launch your AI-built app: the 9 things to check

You built an app with Cursor, v0, Claude, Lovable, or Bolt. It works. You are close to shipping it to real people. This is the checklist I wish every person in that spot would run before they hit deploy.

I have spent about twenty years building software, mostly the parts that handle logins, payments, and who is allowed to see what, for systems used by millions of people. In the last year I have looked at a lot of AI-generated apps. The tools are good. But they are built to make the thing work, not to make it safe to hand to strangers, and those are not the same job.

So here is the list. Go through it before real users show up. Most of these take minutes to check and save you from the kind of week nobody wants.

1. Search your whole codebase for secret keys

Look for anything that resembles a Stripe key, an API key, a database password, or a token sitting directly in the code. Search for sk_, key, secret, password, token. If a real secret is written into a file, it can be read by anyone who sees your code, and bots scan public repos for exactly this, around the clock. Move every secret into environment variables and out of the code.

2. Confirm your repo is actually private, or clean if it is public

If your GitHub repo is public, assume everything in it has been read by an automated scanner already. Even if you deleted a key later, it may still live in your commit history. Check whether the repo should be private, and if a secret was ever committed, rotate it, do not just delete it.

3. Check that users can only see their own data

This is the one that bites hardest. Pick any page that shows something belonging to a user, an order, a profile, a document, and look at the URL. If it has an id in it, like /orders/1043, try changing the number while logged in as a normal user. If you can see someone else's data, so can anyone else. Every request for a specific record needs to check that the record belongs to the person asking, not just that they are logged in.

4. Verify your payment webhook actually checks signatures

If you take payments, your payment provider sends your app a message when someone pays. That message needs to be verified with a signature, so your app knows it truly came from the provider and not from a random person who found the URL. Without the signature check, someone can send a fake "they paid" message and unlock the paid product for free. Confirm the verification step exists and is not skipped.

5. Make sure user input never gets glued into a database query

If your app builds database queries by inserting what a user typed directly into the query text, a user can type a command instead of a search term and read, change, or delete your data. This is SQL injection, and it is completely avoidable by using parameterized queries. Check anywhere user input reaches the database.

6. Look at what your error messages reveal

When something breaks, does your app show the user a full stack trace, a database error, or a file path from your server? Those messages are a map of your system for anyone probing it. Errors shown to users should be plain and generic. The detailed version belongs in your logs, not on the screen.

7. Check that you are not logging sensitive data

Search your code for places where you log or print user information. It is easy to accidentally write passwords, tokens, or personal data into your logs while debugging and then forget to remove it. Anyone with access to those logs then has that data. Clean out anything sensitive from what you log.

8. Pin your dependencies and check for junk packages

AI tools sometimes invent package names that do not exist, or pull in packages with loose version ranges that can change under you. Look at your package file. Confirm every dependency is real, is one you meant to include, and is pinned to a specific version. A surprising dependency is worth thirty seconds of suspicion.

9. Add basic security headers

Your app should tell browsers a few basic rules about how it can be loaded and what it can talk to. Missing headers are not the scariest item on this list, but they are cheap to add and they close off a category of attacks that rely on your app being loaded in places it should not be. This is a quick win before launch.

The honest problem with this list

Every item here is invisible when you use your app normally. You log in, you click around, everything works. The exposed key works fine. The broken access check works fine, because you only ever look at your own data. The app looks finished.

The problems only appear when someone does something you did not think to test, and the people who do that for a living are patient and automated. That is what makes this hard to catch by hand. You are checking for the absence of something, in code you did not write line by line.

The faster way to run this whole list

I built Vibe Code Detector so you do not have to run all nine of these by hand. You paste in a GitHub repo and it checks for every item above and more, exposed secrets, broken access control, missing webhook verification, injection risks, unsafe error handling, risky dependencies, and the quality problems AI tools tend to leave behind. It gives you a plain verdict on whether it is safe to ship, and points you to exactly where the problems are.

The scan is free, and you do not need an account to find out whether your app has a problem. Finding something today is a good day. It means you caught it before someone else did.

Ship the thing you built. Just run the checklist first.