A founder walks into a partner meeting with a forty-screen product. Signup, dashboard, billing, an admin panel, toggles that actually toggle. It took one weekend. Investors are impressed: it looks like six months of engineering compressed into two days.
The round closes three weeks later. A user emails support: they can see another customer's invoices by changing a number in the browser address bar. Nobody on the team had heard the term "permission model," because nothing in the app had ever needed to defend one user's data from another. It only needed to look finished.
The scene above is a composite: pieces of several engagements and founder conversations, not one specific company. The pattern is not made up. We recognize it in the first five minutes of most calls.
That gap, between an app that looks finished and one that is ready for strangers to use, is what this article is about.
The Real Problem: A Demo and a Product Answer Different Questions
A demo answers one question: does this look like it works? A product has to answer a longer list: does it work for a user who is not you, on a device you did not test, with data you did not create, while someone else is trying to break in?
Vibe coding, describing what you want in plain language and letting an AI agent write and run the code, is extraordinarily good at the first question. Nobody built it to answer the second one, because nobody asked it to. You typed what you wanted to see on screen. You did not type "and make sure a logged-in user cannot read another user's records," so in most of these builds, nothing does.
This is not a knock on the tools. A hammer is not bad at turning screws. It was never built to. The mistake is treating a demo-grade build as if it already answered the product-grade questions, because it never got asked them.
What Vibe Coding Actually Is
The term entered common use in early 2025, coined by a well-known AI researcher for a specific way of building: describe the outcome, let an AI agent generate and run the code, iterate by describing what is still wrong. It stuck because it named something a lot of people were already doing.
Used well, it is a legitimate way to reach a working prototype fast, faster than a team of engineers by hand. Used as the entire path to production, with no senior developer ever reading what the agent wrote, it produces software that has never been asked what a real user, a real attacker, or a real outage will eventually ask. Speed was never really the question worth asking here; see how AI-generated code compares to human-written code on raw speed for that part of the argument.
Six Things a Demo Never Needs, and Your Product Cannot Ship Without
Authentication that actually blocks people. A demo needs a login screen, rarely the only way in. Plenty of AI-built apps leave an endpoint reachable without a valid session, because nothing in the demo ever tried to reach it that way.
A permission model. Being logged in and being allowed to see a specific record are two different checks. A demo usually has one user: you. Nothing forces a second check when the first already made the screen appear.
Migrations instead of hand-edited tables. A demo database is built once and never changes shape. A real product changes schema often, and without migration history, every change becomes a manual edit against live data.
Backups and a recovery plan. Nothing in a demo has to survive a mistake. In production, someone eventually runs a command they should not have, and the only thing that matters is whether last night's backup restores cleanly.
Monitoring that tells you before a user does. A demo works when you click it, with you standing right there watching. A product fails quietly, for users you cannot see, unless something is watching on your behalf.
Tests that catch a regression before a customer does. Nobody writes a test for a five-minute demo. Every change after that is a bet that nothing else broke, and eventually one of those bets loses.
Check: pick three of the six above and ask, honestly, whether your app has them. If you cannot answer without opening the code, that is the answer. We cover this ground in more mechanical detail, with rough repair hours for each gap, in the seven ways AI-built MVPs fail in production.
Three Things That Have Already Gone Wrong
None of this is hypothetical. In 2025: an AI coding agent, given production access it should never have had, deleted a company's live database during a routine session. A security researcher found that a meaningful number of apps built on one popular AI app builder exposed user data, because database permissions were never configured behind the login screen. A fast-growing consumer app left a storage bucket open to the public internet, exposing users' photos and identity documents.
Three failure points, one shared root cause: nobody senior had checked the parts of the app that were never visible on a screen.
Ask: if you searched for your own app's storage buckets, admin routes, and database permissions right now, would you know what you would find? A weekend security check for an AI-built app is a reasonable place to start if the answer is no.
Why This Shows Up After the Round Closes, Not Before
A pre-seed demo has an audience of investors clicking through a script they mostly trust. A funded product has real users creating real accounts with real data, and someone is deliberately trying to see what they should not. Users, data, and attackers arrive together, after the check clears, not before.
That is why the incident rarely happens during the raise. It happens in the first few months after, when something that was fine for a demo is suddenly carrying weight it was never built for.
What a Rewrite Actually Costs
Say a review after the round finds the permission model needs rebuilding, not patching. Call it six weeks for two senior engineers, full time, at a blended contractor rate of $150 an hour: 2 engineers x 6 weeks x 40 hours x $150, which is $72,000. On a $1.5 million seed round burning $60,000 a month, that rewrite alone costs more than a month of runway and ships zero new features while it happens.
The number moves with your team and rate. The shape does not: fixing this after the round is always more expensive than building it right the first time, because the second time you are rebuilding while customers already depend on it. We walk through the fuller decision in rewrite or keep your vibe-coded product, weighed against what an MVP actually costs across an agency, a freelancer, and an AI-assisted build.
What We Do Differently
We do not tell founders to stop vibe coding. Speed to a working prototype is a real advantage. What we do is put a senior review between "the demo works" and "the demo has real users," before the gap gets expensive.
That review is not a rewrite. It is a focused audit: authentication and permissions, secrets and access, the schema and its migration path, backups, monitoring, and a check for the kind of gaps described above. Most audits take a few days, not weeks. We come back with a short, ranked list: what is dangerous now, what can wait, and roughly what each fix costs in hours. Some founders want us to fix it. Others just want the list and an ongoing second set of eyes, closer to fractional CTO and technical advisory work than a one-time audit. Either way, the goal is catching the gap while it is still cheap to close.
The Counterintuitive Part
The instinct here is to conclude that vibe coding was the mistake. It was not. The mistake is shipping anything, AI-built or hand-built, without a senior person reviewing the parts a user cannot see. Plenty of hand-coded startups have shipped with the same holes, no permission model, no backups, no monitoring, just built more slowly and billed at a higher rate. The tool did not create the risk. The absence of review did.
The fix is not "hire engineers instead of using AI." It is "make sure someone senior looks at what the AI built," the same way you would want someone reviewing a junior engineer's work, whether the code came from an agent in a weekend or a contractor over a quarter. If your team lacks that senior reviewer, that is a narrower and cheaper problem than most founders assume. Read how to decide between a technical co-founder and a fractional CTO before concluding a full-time hire is the only fix.
What to Do Tomorrow
-
List every place your app touches money or personal data, and write down who checks that a logged-in user can only reach their own records. Verify it, do not assume it.
-
Find your storage buckets and admin routes, and confirm none are reachable without a valid, permission-checked session. This takes under an hour.
-
Book a senior review before your next wave of signups, not after. A short audit now costs a fraction of a rebuild after an incident.
Frequently Asked Questions
Is vibe coding bad for startups? No. It is a fast way to reach a working prototype, and speed matters early. The risk is shipping the output to real users before a senior person reviews authentication, permissions, and the things a demo never needed.
Can I raise a round on a vibe-coded demo? Plenty of founders do, and investors generally understand a raise-stage demo is not production software. The obligation shows up after the round closes, once real users and real data arrive.
Do I need to rewrite my app from scratch? Usually not. Most audit findings are fixable in place: adding a permission model, closing an open storage bucket, setting up backups. A full rewrite is rarely the right first move without checking failure modes and repair cost first.
How do I know if my AI-built app is safe to keep growing on? Check authentication, permissions, secrets, backups, and monitoring, the areas this article covers. If you cannot answer without opening the code, that uncertainty is the signal a review is overdue.
If you raised on a demo and are not sure what is underneath it, schedule a free diagnostic call. We will tell you what we find, whether or not you hire us to fix it.