What Vibe-Coded Apps Get Wrong About Production Readiness

A demo that works when you click through it and a product that's safe with real users and real payments are two different claims, and the gap between them is exactly where AI-assisted "vibe coding" tools quietly leave you exposed. These tools are extraordinary at getting from nothing to a working click-through in a weekend. They are not designed to ask whether that click-through survives a user who doesn't behave the way the happy path assumes.

A demo has one job: prove the idea works, to you, clicking through it in order, with good data. Nothing about that goal requires handling a form submitted twice, a payment that fails halfway through, a request sent with a modified ID, or ten thousand of one thing arriving at once.

Every one of those stays invisible right up until a real user, or a real spike of traffic, creates it — which is usually the first week after launch, not the week you were testing on your own laptop.

The pattern repeats across most AI-assisted builds we review, whatever tool produced them — Cursor, Lovable, v0, Claude, or some combination of all four over a few weekends: authentication that checks the client and not the server, database rules that look configured but aren't actually enforced, no rate limiting on endpoints that clearly needed it, and monitoring that would only tell you something broke if you happened to be looking at the right dashboard at the right time.

None of these are visible in a demo. All of them are visible to an attacker running an automated scan against a newly deployed domain, which happens faster than most founders expect — often within days of going live, sometimes within hours.

Everything above matters more the moment a product takes money. A user account with a security gap is a bad day. A payment flow with the same gap is a chargeback, a compliance question, or — if personal and payment data both leak — a conversation with a regulator. Payment processors also run their own risk review before enabling live payments for a new account, and a codebase with obvious gaps is exactly what triggers extra scrutiny or a delayed approval.

This is also the point where "it worked when I tested it" stops being reassuring. A demo processes one test card, once, on a fast connection, with nobody trying to break it. A live product processes real cards, repeatedly, from people who sometimes make mistakes and occasionally try something deliberately — and the code has to hold up for all of it, not just the first case.

Once a product has an AI feature — chat, generation, scoring, extraction — a new set of failure modes shows up alongside the familiar ones. Prompt injection lets a user steer the model away from its instructions. Nothing capping token usage per user turns one bad actor into a surprising API bill at the end of the month.

Model output landing straight in your database or your users' screens without a check in between assumes the model's response is safe input, when it's really just another input you don't control — no different from a form field a stranger can type into.

None of this means an AI-generated codebase should be thrown out — closing it is usually a defined, fixable list, not a rewrite. That's the actual difference between a demo and a launch: not different code, but a deliberate pass that checks the things a demo never had to survive.

A pre-production security review exists for exactly this moment — the point where something that clearly works needs to become something that's actually safe to put real users and real money behind. Most reviews turn up a short, fixable list rather than a reason to start over. Pairing that review with a team that can also build or extend the product afterward means the fixes get made by people who already understand the codebase, not a third party meeting it for the first time.