Why Vibe-Coded MVPs Break at Scale

Vibe-coded MVPs break at scale for three specific, well-documented reasons. They buckle under real traffic, because they were never built to handle concurrent load. They ship with insecure defaults that expose user data, because speed-first tools default to permissive access rules. And they become unmaintainable as the team grows, because the code was written to prove an idea — not to be extended by someone else later.

None of this is speculation. It's backed by a named CVE, an academic security study, and a widely cited code-quality analysis, all covered below.

This matters more now than it did two years ago. "Vibe coding" — a term Andrej Karpathy (former Tesla AI director, OpenAI founding engineer) coined in February 2025 — has gone from a niche habit to the default way a huge share of new products get built.

In March 2025, Y Combinator CEO Garry Tan told TechCrunch that 25% of YC's Winter 2025 batch had codebases that were 95%+ AI-generated.

"What that means for founders is that you don't need a team of 50 or 100 engineers. You don't have to raise as much."

— Garry Tan, CEO, Y Combinator

That's a real advantage in the first six months of a company's life. It's also exactly why the failure modes below are showing up at scale now, not in a handful of edge cases.

Why does it buckle under real traffic?

An MVP that handled its first 50 users comfortably often starts struggling at 500. This is the most visible failure, and usually the first one a founder notices — because it happens in public, in front of the exact traffic event they were hoping for.

The mechanism is almost always the same. Most AI-assisted builders generate backends on top of auto-generated REST or GraphQL APIs. Supabase's own documentation acknowledges these auto-generated APIs are "often less performant than hand-optimized APIs" — a real architectural tradeoff, not a bug.

On top of that, AI coding assistants frequently reproduce a decades-old but still very real anti-pattern: fetching a parent record, then looping to fetch each related record individually — the classic N+1 query problem. A page that looks instant with ten test rows can quietly turn into hundreds of database round-trips once real data volume shows up, and nothing about that shows up in a demo.

None of this requires one dramatic bug. It's the accumulation of defaults nobody revisited:

• No indexing strategy
• No caching layer
• No connection pooling
• No query review

Each shortcut is invisible on its own. Together, they mean the app was tested for "does it work," never for "does it survive concurrent, real-world load." The first time that gets tested for real is the moment it matters most: a launch, a press mention, a spike from a marketing push.

Why does it ship with insecure defaults that expose user data?

This is the least visible failure and the most dangerous one. It's no longer a matter of speculation — it has a name, a CVE number, and a documented mechanism.

CVE-2025-48757, discovered by security researcher Matt Palmer in March 2025 and disclosed that May, found that Lovable-generated apps make direct calls from the frontend to the underlying Postgres database using Supabase's public "anon" key.

That's expected by design. But it means all real security has to come from Postgres Row Level Security (RLS) policies — and Supabase's own default is that RLS is disabled on a new table until someone explicitly turns it on.

Palmer's scan of 1,645 live Lovable apps found:

• 170 of them — 10.3%, or roughly 1 in 10 — had RLS policies that didn't match their actual business logic
• Real user data, and in some cases credentials, exposed to anyone who queried the database directly
• A CVSS score of 8.26 (high severity)

This isn't a one-tool problem. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models across 80 curated coding tasks and found the models chose an insecure implementation an average of 45% of the time — 86% of samples failed to defend against cross-site scripting, and 88% were vulnerable to log injection.

The pattern is structural: tools optimized to get a working demo shipped fast default to whatever configuration makes the demo work on the first try, not whatever configuration is safe. Reviewing and correcting that default is a deliberate step almost nobody takes before real users — and real user data — start flowing through it.

Why does it become unmaintainable as the team grows?

The third failure is slower and far less dramatic than the first two. But it's the one that quietly caps how fast a company can move once it needs more than one engineer.

GitClear's analysis of 211 million changed lines of code between 2020 and 2024 found:

• Copy-pasted code as a share of all commits rose from 8.3% to 12.3% — a 48% relative increase
• Genuinely refactored ("moved") code fell from 24.1% to 9.5%
• 2024 was the first year on record where copy-paste code exceeded refactored code inside real commits
• Code churn — code rewritten again within two weeks of being written — nearly doubled, from 3.1% to 5.7%, climbing further to 7.1% in 2025 per a later report

That data lines up with how developers actually feel about the code these tools produce. Stack Overflow's 2025 Developer Survey found:

• 84% of developers now use or plan to use AI coding tools
• 46% actively distrust the accuracy of what those tools generate (only 3% "highly trust" it)
• 66% cite "AI solutions that are almost right, but not quite" as their single biggest frustration
• Experienced developers are the most skeptical group of all

Put plainly: the code works, until someone who didn't write it has to change it. That's exactly the moment a fast-growing team hits — usually right after its first non-founder engineering hire.

What does this actually mean for a founder?

None of these three failures mean the MVP was a mistake. Building fast to validate a real idea, with a fraction of the team and budget a traditional build would have needed, is a genuine advantage — not a shortcut to feel guilty about.

The mistake is only in treating that same code as durable production infrastructure once real growth shows up, without ever revisiting the defaults it shipped with.

The fix isn't a full rewrite from scratch. In almost every case, the product itself, the UX, and the parts of the codebase with no significant state or external integrations can stay exactly as they are.

What actually needs rebuilding is narrow and specific:

• The data layer and its access rules
• Anything the app depends on at high frequency
• Whatever a security review flags as genuinely exposed

That's the same three things named above — not a ground-up restart of everything.

That's the exact shape of Ingenetic's Foundation Build offer: a real technical audit first, to find out precisely what's fragile, then a rebuild scoped to only that.

Frequently asked questions

Does fixing a vibe-coded MVP mean starting over from scratch?

No. In most cases the product, the UX, and the parts of the codebase without significant state or integrations can stay. The parts that typically need real rebuilding are the ones tied to growth risk specifically — the data layer, access control, and anything the app depends on at high frequency. A full rewrite is usually the wrong call; a scoped rebuild of the fragile parts is the right one.

How do I know if my MVP actually has a problem, or if it's fine as-is?

Three checks cover most of it:

1. Has anyone reviewed your database's access-control rules since launch — not just whether it works, but whether it's provably safe?
2. Has the app been tested under simulated real traffic, rather than just normal usage?
3. Can a new engineer make a small change without your help?

If you can't answer yes to all three with confidence, that's the signal worth acting on before a growth event forces the question.

Is this a Lovable-specific problem, or does it apply to any AI-assisted MVP?

The best-documented case (CVE-2025-48757) was found in Lovable specifically, but the underlying pattern is not tool-specific. Independent research from Veracode testing over 100 LLMs across 80 coding tasks found AI-generated code chose an insecure implementation 45% of the time on average. The failure mode is structural to how these tools default to speed over safety, not a flaw unique to one platform.

How long does it actually take to harden an MVP like this?

It depends on scope, but the standard shape is: a technical audit first (days, not weeks) to find what's actually fragile, then a rebuild scoped to just those parts. Ingenetic's own Foundation Build engagement runs 2–3 weeks from kickoff once the audit defines the real scope — see How It Works for the exact structure.