April 25, 2026 · vibeprompt · 4 min read
What an MVP Actually Is (Most People Build the Wrong Thing)
Eric Ries defined MVP fifteen years ago. Most people building one today are building something else: a polished v1, a portfolio piece, or a product they're scared to show. Here's what an MVP is for, and how to know when yours is done.
Eric Ries defined MVP as "the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." That sentence is fifteen years old and almost nobody follows it.
What people build instead: a polished v1 with five features, a settings screen, a logo they spent a weekend on, and onboarding they iterated four times. Then they ship it, get five users, and wonder why nothing happened.
The MVP is not a small version of your product. It's an experiment to find out whether your product should exist at all.
The test, not the product
Until someone uses your app and comes back, you haven't validated anything. That's the entire point.
The famous MVPs make this clear. Uber's first version was an SMS line that called you a taxi. Dropbox's was a video. Amazon's was a website that sold one thing: books. None of them were "small versions" of what those companies became. They were tests of one specific question.
Uber's question: will people order rides through their phone? Dropbox's: do people actually want this? Amazon's: will people buy things online sight-unseen?
Your MVP needs to ask one question that clearly. If you can't write the question down in one sentence, you don't have an MVP, you have a feature list.
The four-question check
A done MVP passes all four:
- One core feature works end-to-end. Not five features each half-finished. One feature, fully working.
- You can demo it in 60 seconds. If your demo needs setup, context, or "imagine that...", it's not done.
- A stranger can use it without help. Not a friend who already knows what you mean. A stranger.
- You're slightly embarrassed by it. Reid Hoffman's line: "If you're not embarrassed by the first version of your product, you've launched too late."
If three of these are true and one isn't, you're either over-building or under-finishing. Both are fixable. Neither is shippable.
The shape of a real MVP
A real MVP looks underwhelming. That's correct.
A todo app's MVP is a list with one twist that makes it different from every other todo app. No themes. No settings. No tags. No accounts.
A tracker app's MVP is one counter on one screen with one button. No history view. No charts. No export.
A finance app's MVP is an input field, a calculation, and a result. No accounts. No saved data. No comparison feature.
The pattern: ship the absolute smallest thing that demonstrates the value, then let real users tell you what to add. Most of the things you'd add by guessing are wrong. You only learn that by shipping the small thing first.
The timeline that works
Three weeks. That's the sustainable shape:
Week 1: Core feature works. Just the engine. Ugly UI is fine.
Week 2: Basic UI plus internal testing. You and three honest people use it daily.
Week 3: Ship to real users. Not friends. Real target users.
If you're in week 6 still building, you're no longer building an MVP. You're building a v1 and you skipped the validation step. The fix isn't more features, it's shipping what you have and finding out which features matter.
The mistakes that kill MVPs
Almost every failed MVP fails for one of four reasons.
Too many features. The list grows from three things to twelve before you write any code. Twelve things take ten times as long, and ten of them are wrong. Cut to one.
Waiting for perfect. Perfect is shipped. There is no other definition. Every week you spend polishing before launch is a week you didn't get user feedback that would have told you what was actually worth polishing.
Ignoring feedback. You ship, users tell you the thing is broken, you tell yourself they don't get it. Sometimes they don't. Usually they do. Listen to behavior, not your ego.
Mistaking interest for usage. "Looks great, I'd totally use that" from a friend is not validation. Five strangers who came back the next day is. Track retention, not compliments.
The kill criterion
Write this before you start building, in your spec: "If [specific signal] doesn't happen by [specific date], I stop."
For example: "If I can't find ten real complaints about this problem on Reddit in one hour, I stop." Or: "If fewer than five of twenty testers come back the second day, I pivot."
You will not enforce a rule you wrote after building for two months. You'll have too much sunk cost. The kill criterion only works if you commit to it before you've spent anything you can't walk away from.
This is the single most underused habit in MVP building. Most people don't have one. They keep building until they run out of energy, money, or both. The people who ship multiple things are the ones who knew when to stop on the things that weren't working.
What you're actually doing
The MVP is not the product. It's the experiment that tells you whether building the product is worth the next six months.
Ship in under three weeks. Be slightly embarrassed by it. Show it to strangers. Watch what they do, not what they say. Decide based on behavior whether to keep building, pivot, or move on.
That's the whole loop. Everything else is procrastination dressed up as work.