90% of MVPs Are Fake: The Real Definition of MVP

It's V (Viable), not M (Minimum), that decides the fate of your MVP.

The delivery app that spent 6 months and failed

There's the story of a delivery-platform startup. The founders confidently declared "we'll build an MVP" and then worked for 6 months. Payments, reviews, coupons, recommendation algorithms — they shipped only after all of it was in place. They thought it was "the perfect MVP."

Then they hit the market and a problem detonated. They had gone all the way through without ever validating the most basic value — connecting restaurant owners with customers. By the time they realized, it was already too late.

After reading this post, you'll be able to diagnose precisely whether what you're building right now is a "real MVP" or "a finished product cosplaying as an MVP."

The trap of "Minimum": it's not features, it's validation

When people build their first MVP, they almost always make the same mistake: they focus only on "M (Minimum)." The goal becomes "as few features as possible," "as fast as possible," "as cheap as possible." So they open a spreadsheet and the question becomes not "what feature do users really need?" but "is 5 features enough, or should I push it to 10?"

Eric Ries defined the MVP in The Lean Startup like this:

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

The point isn't "number of features" — it's "learning." What you really need to confirm is "will people use this?" Whether it's 5 features or 20 doesn't matter. What matters is whether those features actually validate the hypothesis you need to test.

Too few features makes it not an MVP but an "incomplete product." Too many features without validating the core value is just "high-fidelity waste."

MVP vs Beta vs Prototype — drawing the lines

These three get mixed up a lot, but they have different purposes, audiences, and timing.

Look at Daangn's early MVP. It started with just two features — "make a request" and "see the items offered." Everything else was done by hand. They literally called local agencies. Matching logic? None. A human did it. Pretty UI? None. They handled inquiries through KakaoTalk.

But this counted as a real MVP because they could validate the core value: "people register their intent (a request for an item), and they get items back."

The 4 conditions of a good MVP

1. The core hypothesis is sharp

"Will people use our service?" is too big. It should be specific, like "Will 25–35-year-old Seoul office workers buy a simple meal that can be ordered in under 5 minutes during lunch, more than twice a week?"

Toss's early hypothesis was "If we can send money 10x faster than existing banking apps, will people use it?" So they built only money transfer, perfectly. The rest didn't even have a button.

2. The user actually solves a real problem

They have to feel "this idea is the answer." Free or paid, perfect or 70%, doesn't matter. Daangn users felt "I can actually find items with this app." That was the signal that the MVP was working.

3. It's measurable

How do you know whether users really felt the problem? With numbers. Signups, active users, purchase counts, return rates. "I got great feedback" is not a measurement. Mouths lie; fingers don't. Did they reopen the app? Did they buy? Did they recommend it to a friend? That's the evidence.

4. You can change direction quickly when the hypothesis is wrong

If you spent 6 months building it, can you change course? When the investment is huge, even "is this off?" doubts can't move the wheel — psychologically or financially. If you built it in 2 weeks, you can shrug, say "ah, this isn't it," and move on to the next idea. The chances of your first MVP succeeding are very low.

3 wrong MVP patterns to avoid

Pattern 1: A finished product cosplaying as an MVP

Like the delivery platform above. The psychology is "I actually want to build a finished product, but I'll call it an MVP." Usually justified with "this is a real product for real users, so it has to be perfect."

Recovery: Cut 3 "nice-to-have" features from what you're building right now. Is it OK to handle support over KakaoTalk? Is it OK to start with manual work instead of an automated algorithm?

Pattern 2: An MVP that's too small

The other extreme. People build at prototype quality and call it an MVP. The user can't actually solve their problem with it. So either there's no feedback, or all you get is "build more please." That's not a market signal.

Recovery: Ask "can the user really solve my problem with this?" If not, write down what would actually need to be there.

Pattern 3: An MVP with no measurement

The most common. People build and launch an MVP and then never look at data. They set their next direction based on two or three pieces of user feedback.

Recovery: Decide "which metrics am I going to look at?" before launch. Set up Google Analytics, signup data, active-user tracking, repurchase rate.

Checklist: is my idea really an MVP?

Answer these 10 questions. If 7+ are "yes," it's a real MVP.

1. Is my core hypothesis defined in one sentence?
2. Are the features needed to test that hypothesis clearly defined?
3. Can a user actually solve their real problem with just those features?
4. Is development expected to take under 8 weeks (ideally 2–4)?
5. Within the first 5 minutes, can a user feel "ah, this solves my problem"?
6. Is it OK to use manual work or KakaoTalk-based support?
7. Are you mentally ready to move on to the next MVP if the hypothesis is wrong?
8. Have you chosen 3 core metrics to measure post-launch?
9. Has someone outside (a customer) used it and given you feedback?
10. Did you cut 3+ "not really needed" features last week?

Wrapping up

Now you know M (Minimum) is the trap and V (Viable) is the point. Then the next question comes: "So what should I build?" You have lots of ideas — how do you choose? The next post introduces a 5-question framework for diagnosing your idea. It asks not "can you build it?" but "can you stick with it for a year?" Because the success of an MVP comes from your perseverance, not from the product.

Previous: Why You Should Build an MVP Now (The 14-Day Maker Era)
Next: 5 Questions Before Building (A Sustainability Check)

Minchul Kim, CEO of Freeive, Fail School