"Just build an MVP" is the most repeated — and most misunderstood — advice in software. Founders hear it and picture either a cheap, half-finished app, or somehow a smaller version of the full thing. Neither is right, and the confusion costs real money.
Here's what an MVP actually is, in plain English.
What an MVP actually is (and isn't)
MVP stands for minimum viable product. The important word is viable — it has to genuinely do the one job that proves people want it. It is not a broken prototype, and it is not "version one of everything, but worse."
A good MVP does one thing well enough that a real user will use it, pay for it, or give you a clear signal. Everything else waits.
Why "minimum" trips founders up
The trap is treating "minimum" as "cheapest possible." That leads to corners cut in the wrong places — no error handling, no security, a payment flow that breaks. That's not minimum, it's fragile.
Minimum means fewest features, not lowest quality. The features you keep should still work properly.
MVP vs prototype vs proof of concept
These get used interchangeably, but they answer different questions:
- Proof of concept (PoC): "Is this technically possible?" Throwaway.
- Prototype: "Does this feel right?" A clickable mock-up to test the idea with users. Usually throwaway.
- MVP: "Will people actually use/pay for this?" Real, working software you can put in front of customers.
If someone hands you a "prototype" and calls it an MVP, be careful — a demo that looks real and software that is real are very different amounts of work. I wrote more about that gap in taking a vibe-coded prototype to production.
What belongs in your MVP
Ask one question of every proposed feature: does this prove the core assumption? If not, it waits.
For most products the MVP is:
- The single workflow that delivers your core value
- Just enough account/auth to make that workflow real
- A way to get feedback or take payment
- The non-negotiable basics: it's secure, it doesn't lose data, it doesn't fall over
That last line matters. "Minimum" never includes "insecure" or "loses customer data."
Common MVP mistakes
- Building for scale you don't have. You do not need microservices for 50 users.
- Adding "just one more" feature. Every one delays the learning you're actually after.
- Skipping the boring basics to save money, then paying to bolt them on later.
- No way to measure success. If you can't tell whether the MVP worked, you built the wrong thing.
How to scope one
Write down the single assumption you're testing. List only the features required to test it. Cut everything else to a "later" list. Then get an honest estimate — and if the number surprises you, my guide to what a custom app actually costs explains what drives it.
If you want a second pair of eyes on your scope before you commit budget, that's exactly the kind of thing I help founders with. Book a free call and we'll pin down what your MVP really needs — and what it doesn't.