Your Vibe Prototype Is Not an MVP

A few weekends ago I opened Lovable and typed out what Outcomet should look like. By Sunday evening I had a working app. Signup, dashboard, the core loop. It ran.

For about twelve hours, I caught myself thinking I had built an MVP.

Then I sent the link to three people I'd been talking to about the problem. Two never opened it. One clicked through once and wrote back with a kind version of "interesting, let me know when it's ready." That's when I realized what I actually had.

I had a working app. I didn't have a learning loop. And that's the distinction the entire "I built an MVP this weekend" genre keeps missing.

The Weekend Build Isn't Where the Work Is

If you spend much time on LinkedIn right now, you've seen the posts. Someone opened Cursor or Lovable or v0, typed a prompt, and 48 hours later announced they'd shipped an MVP. Sometimes with a screenshot of a landing page. Sometimes with a screen recording of a signup flow that works.

The speed is real. AI tools compressed the build phase of product work. Weeks became days. Days became hours. That part is not a vibe. You can, in fact, have a running application by Sunday night that would have taken a team two sprints a few years ago.

But somewhere in that compression, the word "MVP" got flattened along with the build. And the flattened version is doing a lot of damage.

Because an MVP was never really about the thing being built. It was about what the thing let you learn.

What Ries Actually Meant by "Viable"

Go back to the source. In The Lean Startup, Eric Ries defines an MVP as:

"that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

Read it again. There's no mention of code. No mention of a UI. No mention of shipping, deploying, or even building anything resembling a product in the way we normally use the word.

The whole definition orbits around validated learning. The MVP is an instrument. Its job is to produce real data from real customers about a real hypothesis. Build, measure, learn. The building is one-third of the loop.

Ries's own examples make this obvious. Food on the Table started as a human being sending meal plans to one family, by email, every week. Dropbox's early MVP was a video of a product that didn't exist. Zappos started with Nick Swinmurn walking into shoe stores, photographing the inventory, and posting the pictures online with no backend. If someone ordered, he bought the shoes from retail and shipped them himself.

None of those were weekend Lovable builds. They weren't impressive. They weren't polished. They worked because each one produced a measurable answer to a specific question about customer behavior.

The Learning Loop Is the Product

Here's what I noticed after my Lovable weekend. The app was the easy part. What I actually still had to do was find the right prospects, get them on a call, get them to open the thing more than once, and get them to tell me the truth about why they didn't.

Every one of those is harder than the build, and none of them are things AI has flattened. A model can generate you a signup flow in minutes. It cannot find you twenty product managers who have the exact problem you think you're solving, get them to care, and get them to be honest with you about what's actually in their way.

If you step back, this is the structural issue. Vibe prototypes capture the output of the build-measure-learn loop while skipping the measure and the learn. You see the result of the first third and assume the other two-thirds happened in proportion. They didn't. They usually didn't happen at all.

What Vibe Prototypes Leave on the Floor

When an MVP skips the learning loop, a few specific things go missing, and most of them stay invisible until much later.

You lose problem clarity. You built something that solves a problem, but you haven't tested whether it's the problem people would pay to solve. You have a solution in search of a specification.

You lose validation. You don't know if the form you picked is the right form. Maybe the people you're targeting needed a spreadsheet, not an app. Maybe they needed a Slack integration, not a dashboard. The build locked you into a shape before you tested whether the shape was right.

You lose the feedback signal. Three people ignoring your link is data, but it's ambiguous data. Was it the framing? The problem? The moment? You can't tell, because you picked speed of building instead of speed of learning, and you have no instrumentation for the second one.

The build is not the MVP. The build is the artifact. The MVP is what the artifact helps you learn.

From Build Velocity to Learning Velocity

The interesting shift is that AI didn't make MVPs obsolete. It made build velocity close to free, which means the bottleneck moved. It's now sitting right where Ries said it was all along: in the loop.

The product teams I watch doing this well aren't racing to ship. They're racing to learn. They use the vibe build as a cheap probe, not as a finished artifact. They put it in front of five carefully chosen people within 48 hours of generating it. They watch what those people do and don't do. They rewrite their hypothesis, scrap the probe, and generate a new one.

That's a very different discipline from "I built an MVP this weekend." It's closer to "I ran my third hypothesis this week." The vibe build is an input to the process, not the output of it.

What Actually Got Faster

Here's the part I didn't expect when I started building Outcomet. AI didn't make product development faster. It made one phase of product development close to free, and exposed how much of the rest of the work is the actual work.

The teams who figure that out first are the ones who'll ship products people use. The ones who don't will keep announcing weekend MVPs that nobody opens twice.

If your MVP didn't change what you believe about your customer, it wasn't an MVP. It was a prototype with good vibes. And prototypes are useful. They're just not the same thing.