I keep seeing the same post. Different account, different week, same idea.
Someone who isn't an engineer has an app idea. They open an AI coding tool and vibe their way to something that runs. A login screen. A dashboard. A working demo on their laptop. And then comes the plan, stated with total confidence:
"I'll build the MVP myself, then hire an engineer to take it to production."
The logic underneath it never changes. The MVP is the hard part. I've done the hard part. Now I just need to pay someone to polish it, scale it, and ship it — and because most of it already exists, that part should be cheap and fast.
I want to be gentle here, because I genuinely love that people are building. The barrier to entry collapsing is one of the best things that has ever happened to this field. But this specific plan is backwards. Not slightly backwards. Completely backwards.
The part you skipped is the part that mattered most.
The Decisions Happen Before the First Line
Here's what fifteen years of building software taught me: the most expensive decisions on any project are made before anyone writes a line of code.
Is this going to serve one user or ten thousand? Does it run on your laptop, or does it run in the cloud where other people can reach it? Where does the data live, and what happens when two people change the same thing at the same time? Is this one customer's app, or is it a platform that a hundred companies will each have their own private slice of? How do people log in, and what stops one of them from seeing another one's data?
None of those are coding questions. They're architecture questions. They get answered at the very beginning, and every line of code written afterward is built on top of the answers. Change one of them later and you're not editing code — you're pulling out the thing everything else is standing on.
A vibe-coded MVP answers all of those questions. That's the part nobody realizes. It doesn't skip them — it can't skip them, because the software has to do something. It just answers them silently, by default, in whatever way got a demo running the fastest. One user. Your laptop. Data in a file next to the code. No real login. No concept of a second customer.
Every one of those defaults is the wrong answer for production. And you didn't choose any of them. They got chosen for you, by a model optimizing for "make the demo work," and now they're load-bearing.
The Demo Is the Trap
The reason this misconception is so sticky is that the demo works. You can click through it. It looks eighty percent done.
But it works the way a movie set works. Walk up to the storefront and it's a plywood face with nothing behind it.
It runs on your machine, for exactly one user — you. There's no real data in it, so you've never seen what happens when there are fifty thousand rows and the page takes nine seconds to load. Nobody else is using it at the same time, so you've never hit the bug where two people book the same slot. It's talking to a database sitting in a file on your hard drive, which means the moment you need it to run somewhere other people can reach, it doesn't. None of the boring, invisible, absolutely essential machinery of a real application is there — because none of it was needed to make the thing on the screen move.
I work in the steel industry, and there's an analogy I can't shake. You don't get to decide a beam's load rating after it's already set in the building. The rating is a decision you make at the start, based on what's going to sit on top of it, and it determines everything about the beam you order. Deciding "actually this needs to hold three floors" after it's welded in place doesn't mean a quick upgrade. It means cutting it out and starting over.
Software has load ratings too. You just can't see them, so it's easy to believe they aren't there.
Why the Engineer Can't "Just Finish It"
So the engineer you hire to "take it to production" opens the project, and here's what they actually find: not eighty percent of a building, but a full set of foundational decisions that were made by accident and are all wrong for where you want to go.
Now they have two options, and both cost you.
They can tear out the foundation and rebuild it correctly — which means most of what you made gets thrown away, and you're paying full price for the real work while feeling like you're paying twice. Or they can try to preserve your MVP and bolt production-grade architecture onto decisions that fight it every step of the way, which is slower, buggier, and more expensive than if they'd started clean.
Ask any engineer which they'd rather inherit: an empty folder, or a working prototype built by someone who didn't know what a foundation was. A lot of us would take the empty folder. The prototype isn't a head start. It's a set of constraints we didn't choose, plus a customer who thinks the job is almost done.
And that last part is the real killer. Because you watched it work on your laptop, you are now certain it's ninety percent finished. So when the engineer tells you the real work is three months, it doesn't sound like the truth. It sounds like they're padding the estimate or they're not very good. The vibe-coded MVP didn't just fail to save you money. It anchored your expectations to a number that was never real, and it made the person doing the actual work look slow for doing it.
The Multiplier Cuts Both Ways
I've written before that AI is a capability multiplier, and the thing it multiplies is what you already bring to the table. That cuts in a direction people don't like to sit with.
When I sit down with an agent, I've already made the foundational decisions in my head before I open the terminal. The data model, where it runs, how it scales, how tenants are isolated — that's the actual work, and the AI never sees most of it. It just types out the implementation of choices I already made. The architecture is mine. The typing is the model's.
A non-engineer vibe-coding an MVP is running the same tool with the multiplier set to zero on exactly the part that matters. There's no architectural judgment going in, so there's no architectural judgment baked into what comes out. That's not a knock on the person — you can't apply a framework you haven't learned yet. It's just the reason the output can look finished and be structurally hollow at the same time. The tool faithfully multiplied what it was given.
The Actual Point
Vibe-coding an MVP is genuinely, unambiguously valuable — for the right job. It's the fastest way to find out if an idea is worth anything. It's a demo you can put in front of an investor or a customer. It's how you decide whether to build the real thing at all. If that's what you're doing, go do it, and have a great time.
Just don't confuse it with a down payment on production. It isn't one. The demo and the product share a screen; they do not share a foundation.
If production is the actual goal, the engineer's most valuable hour isn't the one after your last line of code. It's the one before your first. That's when the decisions that cost the most get made — scalable or not, cloud or laptop, one customer or a hundred, where the data lives and who's allowed to touch it. Get someone who knows what those decisions do in the room then, and you'll spend less and ship something real.
Hire the engineer before the foundation, not after the walls. You can't vibe-code a foundation. You can only vibe-code the thing that falls down without one.