Vibe coding got you an MVP. Now what?

David Melich

TL;DR: Vibe coding is the best demand-validation tool the software industry has ever produced — and what it gives a non-technical founder is a proof of concept, not an MVP. The "viable" in minimum viable product means safe to rely on: security, data, infrastructure. That part still has to be engineered. Here's what breaks, and what the bridge to production looks like.

You built in three weekends what would have taken a development agency four months and a five-figure invoice. The demo landed. People want it. And somewhere behind the excitement there's a quieter thought you keep postponing: you can't put paying customers on this thing.

This article is about that thought. Not to talk you out of it — to tell you it's the most useful instinct you have right now, and what to do with it.

We thought vibe coding was the end of our MVP business

In autumn 2025, watching the vibe coding wave build, we honestly thought our MVP-building market was gone for good. Another shiny object, sure — the industry produces one every eighteen months — but this one was different. The sheer weight of hope and expectation loaded onto it was unlike anything I'd seen in 20+ years of building software.

Vibe coding (also called AI-assisted app building) is the practice of describing what you want in natural language and letting an AI generate the application — in tools like Lovable, Bolt, Replit, or Cursor. Andrej Karpathy coined the term in February 2025: "fully give in to the vibes, embrace exponentials, and forget that the code even exists," as he put it — a description MIT Technology Review notes was written half in jest, about weekend throwaway projects. The market skipped the "half in jest" part.

Here's where I landed after months of talking to founders who tried it: not everything is gold that shines, but this actually is a gamechanger — for a different stage of the product than everyone assumed.

It has never been easier to put together something that looks and feels like a real product, go to real people, and try to sell it to them. That's not a small thing. Demand validation used to cost months and real money. Now it costs a few evenings and a subscription. As a market research and product-market-fit instrument, vibe coding is the best thing that has happened to founders in a decade.

The trouble starts with what you call the result.

What you built is a PoC, not an MVP

MVP stands for minimum viable product. Not minimum viable prototype, not minimum viable demo. The word doing the work in that acronym is "viable" — and viable means someone can rely on it in her business and be safe doing so. No silent data loss. No open door to whoever cares to look. No 2 AM discovery that the thing everyone's livelihood depends on was held together by defaults nobody understood.

What a non-technical founder gets out of vibe coding is a proof of concept: a working demonstration that the idea makes sense and people respond to it. That is genuinely valuable — most startups die without ever getting that far. But a PoC and an MVP are different animals wearing the same UI. The difference is everything you can't see in a demo: authentication that actually authenticates, a database that doesn't hand out its contents to strangers, error handling, backups, monitoring, an architecture that survives its second real user.

The demo working is evidence of demand. It is not evidence of a product. Founders who collapse those two into one word — and the whole ecosystem encourages them to — make every downstream decision on a false premise.

	Proof of concept (what you have)	MVP (what customers need)
Proves	People want this	People can rely on this
Security	Whatever the tool generated	Designed, reviewed, tested
Data	Works until it doesn't	Protected, backed up, recoverable
Failure at 2 AM	Nobody knows the code	Monitored, debuggable, on-call ready
Right audience	Prospects, investors, pilots	Paying customers
Built by	Anyone with an idea	Someone who understands infra

What actually breaks first

This isn't hypothetical. In the past months I've talked with several founders about their vibecoded apps, and the pattern in those conversations repeats: the app works, users are signing up, and nobody involved can answer the question "what happens to the data if someone hostile shows up?"

The public record answers it for them. In 2025, CVE-2025-48757 revealed that Lovable had been generating applications on Supabase databases without row-level security — over 170 production applications confirmed exposed, CVSS score 9.3. In plain language: anyone with the public key every browser receives could dump entire tables. User lists, payment records, API keys. No hacking skills required — you just had to ask the database, and it answered.

The founders running those 170+ apps weren't stupid. They did what the tool made easy, shipped what looked done, and had no way of knowing what they hadn't checked.

And the code itself carries the same pattern. Veracode's 2025 GenAI Code Security Report tested over 100 large language models on 80 coding tasks: when there was a secure and an insecure way to write the code, models picked the insecure one in 45% of cases — a rate that hasn't improved with newer model generations. GitClear's analysis of 211 million changed lines of code found copy-pasted code rising from 8.3% to 12.3% of all changes between 2020 and 2024, while refactoring — the work that keeps a codebase maintainable — collapsed from 24.1% to 9.5%.

Read those two studies together and notice something: that's the damage measured on professional teams, where an experienced developer reviews what the AI writes. Now remove the reviewer. That's a vibecoded app.

The guy on the podium

Some time ago I stood in an audience while a speaker — a well-known vibe coding evangelist — told the story of how vibe coding changed his company's trajectory. Confident, fluent. The crowd loved it.

Mid-talk, a friend of mine leaned over and quietly asked if I wanted to see what that trajectory pays. He'd seen the inside of those celebrated solutions. His verdict, whispered under the applause: dangerous, and full of security holes.

That contrast — the stage story and the whisper — is the thing that actually makes me angry about this whole wave. Not the tool. The tool is remarkable. What angers me is what happens when something this powerful lands in the hands of someone who doesn't know what he doesn't know, and doesn't care to find out. The Dunning–Kruger effect with a deploy button. His customers will pay for that ignorance — with their data, possibly with their businesses — long before he ever does.

Here's the part that matters for you, though. If you're the founder from the first paragraph — the one with the quiet dread about putting paying customers on your vibecoded app — you are, by definition, not that guy. The dangerous founder feels nothing. Worrying about what you can't see is not a weakness in this game. It's the qualification.

The rebuild math quietly flipped

The throw-it-away-and-build-it-properly pattern isn't new. Founders were showing up with broken first versions long before AI — it's the oldest pattern in our business. Tentacles, a Dutch IoT company we've worked with since 2019, came to us exactly that way: a failed supplier build, a product that couldn't ship, a company bleeding money on it.

But in the pre-AI era, the economics usually argued against throwing anything away. First builds took months and cost serious money, so even when the foundation was bad, it made more sense to fix up the worst parts and keep going. Reasonable people, reasonable math — I've written about how we walk that rescue-or-rebuild decision with founders whose projects failed.

Vibe coding broke that math from both ends at once.

Your side: the thing you'd be throwing away cost three weekends, not €100k. There's no sunk cost worth defending. What you actually built — and what you keep, in full — is the validated learning: proof of demand, product decisions tested on real people, screens and flows users already responded to. The disposable part is only the code.

Our side: AI changed the cost of building properly, too. Rewriting a validated PoC into a production system used to be a multi-month, six-figure proposition. It isn't anymore — 81% of executives say tech debt already constrains what they can do with AI, which is precisely why starting clean, with AI acceleration on a foundation designed by people who understand foundations, has become the cheap option rather than the expensive one.

When throwing away is nearly free and rebuilding properly got dramatically cheaper, patching a vibecoded PoC into shape is the one option that almost never makes sense. It's the worst of both worlds: rescue-level effort spent on a foundation that was never designed to carry load.

Now what: the honest bridge to production

So you've validated demand with a vibecoded PoC. People want the thing. The bridge to a real product has one non-negotiable property: from here on, someone who understands tech and infrastructure has to be involved. Not necessarily as employees — but the "forget that the code even exists" phase is over the moment real customers rely on you.

In practice the bridge is a rewrite. Either the PoC's code gets rewritten properly, or — more often — it gets thrown away entirely and the product is built fresh, with the PoC serving as the richest spec document a development team has ever received. Call it vibe engineering if you like: the same AI acceleration you used, now operated with senior judgment, tests, and architecture underneath it.

This is exactly what we've built our delivery around. We run an agentic delivery pipeline, under senior engineers' judgment, that can take a vibecoded PoC, go through its UI and source code, and rebuild it properly — test-first, with full test coverage, without losing the functionality you validated. The product decisions you paid for with those three weekends survive intact. The security holes don't.

What that costs, concretely: our audit — where we scan what you have and tell you honestly what's salvageable and what the rebuild takes — is €5,000 flat. A production rebuild of a validated PoC typically lands in the €25,000–75,000 range depending on scope, delivered in weeks rather than quarters. Compare that against what the cost of unmanaged technical debt compounds into once you have paying customers on a broken foundation, and the sequencing argument makes itself: validate cheap, then build once, properly.

Keep vibecoding — just know what it's for

Here's where I part ways with the doom pieces. The lesson of all this is not "stop vibe coding." The lesson is to aim it at the stage it actually wins.

Vibe code your next idea before committing money to it. Vibe code the demo for the investor meeting. Vibe code internal tools where the blast radius is your own team's patience. Vibe code the prototype of the next feature and put it in front of users before your dev team builds it for real. Every one of those uses plays to the tool's actual strength: making "let's see if anyone wants this" nearly free.

Just don't put paying customers' data on it. The moment someone relies on your product in her business, you've crossed from validation into production — and production is an engineering discipline, not a vibe.

You didn't build an MVP in three weekends. You built something arguably more valuable: proof that the MVP deserves to exist. That's the hard part of startups, and it's done. Now finish the job properly.

FAQ

Is vibe coding good for building an MVP?

It's excellent for building a proof of concept and validating demand — putting something that looks like a real product in front of real users within days. But the output of vibe coding by a non-technical founder is a PoC, not an MVP: it lacks the security, data integrity, and infrastructure that make a product viable for paying customers.

What's the difference between a PoC and an MVP?

A proof of concept demonstrates that an idea works and people respond to it. A minimum viable product is something customers can safely rely on in their business: secured, tested, monitored, recoverable. Vibe coding tools produce the first and make it look like the second — that gap is where founders get hurt.

Can a vibecoded app go to production?

Not safely as-is, in our experience. Vibecoded apps have repeatedly shipped with critical security gaps — the Lovable CVE-2025-48757 disclosure confirmed 170+ production apps exposing their databases. Going to production means a proper rewrite, or a fresh build that treats the vibecoded app as a validated specification.

Should I throw away my vibecoded app?

Usually yes — and it costs less than it sounds. The code is the disposable part; the validated demand, product decisions, and tested user flows carry over fully into the production build. Patching a vibecoded foundation is typically the most expensive path, because the rebuild economics have flipped: AI-accelerated professional delivery made building properly cheap, and the PoC cost you almost nothing.

Is AI-generated code secure?

Not by default. Veracode's 2025 testing of 100+ language models found they chose an insecure implementation in 45% of tasks where a secure option existed, and the rate hasn't improved with newer models. Professional teams catch these issues in review; a non-technical founder has no reviewer.

What is vibe engineering?

Using the same AI acceleration as vibe coding, but operated by people who understand architecture, security, and infrastructure — with tests, senior review, and deliberate design underneath. It's how AI speed and production quality stop being a trade-off. This is how we deliver rebuilds at GrownApps.

How much does it cost to turn a vibecoded PoC into a real product?

Our audit is €5,000 flat: we scan the app and its code and tell you honestly what a production version requires. A typical rebuild of a validated PoC runs €25,000–75,000 depending on scope, delivered in weeks. The PoC itself keeps earning its keep as the specification for the rebuild.

Your PoC did its job. Now build the product.

If people want what you vibecoded, you've already won the round most founders lose — you validated demand before spending real money. The next round is won differently: with engineering. If you're staring at a working demo and that quiet "can I actually sell this?" feeling, our €5,000 audit is built for exactly this moment — we scan what you have, tell you what's salvageable, and give you the honest path to production. And if you want the longer version of how founders end up here, read what to do when a software project fails.