I shipped an app I built with AI. Here is what went wrong in the first week.

You built something. It works. You typed what you wanted, the AI wrote the code, you clicked deploy, and now there is a real URL that real people can visit. That feeling is incredible, and I do not want to take it away from you.

But I have spent about twenty years building software, most of it on systems that handle logins, payments, and access control for millions of people. And I have looked at a lot of AI-generated apps in the last year. So I want to tell you, plainly and without the scary-consultant act, what actually tends to go wrong in the first week after a vibe-coded app meets real users.

None of this is a knock on Cursor, v0, Claude, Lovable, or Bolt. They are genuinely good. But they optimize for making the thing work, not for making the thing safe to hand to strangers. Those are different jobs, and the gap between them is where people get hurt.

Here is what lives in that gap.

The API key that was sitting in plain sight

The most common thing I see, by a wide margin, is a secret key committed right into the code. A Stripe key, an OpenAI key, a database password. It works perfectly in testing, so nobody notices.

The problem is that anything shipped to the browser, or pushed to a public repo, is readable by anyone who cares to look. Bots scan public GitHub repos for exposed keys constantly, and they are fast. There are well-documented cases of a leaked cloud key turning into thousands of dollars of charges overnight, because someone found it and spun up servers on your account to mine crypto.

You will not get a warning. You will get a bill.

The user who could read everyone else's data

This one is quieter and worse. It is called broken access control, and the common version is that your app checks whether someone is logged in, but not whether they are allowed to see the specific thing they asked for.

So a user logs in, lands on a page like /orders/1043, and out of curiosity changes it to /orders/1044. And they see someone else's order. Their name, their address, maybe their card details. The app never checked that order 1044 belonged to them, because the AI wrote the "fetch the order" part and not the "make sure it is their order" part.

Nobody notices this until a user notices it. And when a user notices it, they do not email you. They post a screenshot.

The payment webhook that trusted anybody

If you took payments, you probably have a webhook, a URL that your payment provider calls to say "this person paid." A lot of AI-generated versions of this take that incoming message at face value and unlock the paid features.

The issue is that your webhook URL is not really a secret, and a message claiming "this person paid" can be sent by anyone who finds the URL. Without a signature check, your app cannot tell the difference between your payment provider and a random person typing a fake "they paid" message into a terminal. So people get the paid product without paying, and you find out when your revenue does not match your usage.

The form field that talked directly to your database

Classic SQL injection. Your app takes what a user types into a search box or a login field and builds a database query out of it. If the code glues the user's text straight into that query, a user can type something that is not a search term at all, but a command. Read every row in the table. Delete it. Dump the whole user list.

This one is decades old and completely solved by writing the query the right way. But "the right way" is a habit, and generated code does not always have the habit.

Why you cannot see any of this yourself

Here is the part that makes this genuinely hard, and why I am not just telling you to "be more careful."

Every one of these problems is invisible when you use the 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 unsigned webhook works fine, because you are not attacking yourself. The app looks done.

The problems only show up when someone does something you did not think to test. And the people who do that for a living are patient and automated.

You did not do anything wrong. You built with the tools available, and the tools are good at building. Catching this class of problem is a different skill, and it is one you can borrow instead of spending years learning.

What to actually do before you ship

Scan your code for this specific class of problem before real users touch it. That is the whole message.

I built Vibe Code Detector to do exactly this. You paste in a GitHub repo, and it checks for the things above and more, exposed secrets, broken access control, missing webhook verification, injection risks, the quality and structure problems that AI tools tend to leave behind. It tells you plainly whether it is safe to ship, and where the problems are.

The scan is free and you do not need an account to see whether your app has a problem. If it finds something, that is a good day, because you found it before someone else did.

Ship the thing you built. Just check it first.