You've been quoted for "an MVP." Someone used the term confidently, you nodded along, and now you're looking at a scope document wondering whether what's in there is the right size — and whether the price matches it.
That's the exact question this article answers: what MVP meaning actually is in the software context, and what it should mean for your scope and budget decisions.
- What MVP stands for
- What "minimum" actually means
- What "viable" actually means
- What an MVP is not
- How to scope your MVP
What MVP stands for
MVP stands for minimum viable product. The term comes from Eric Ries' book The Lean Startup (2011), which introduced the idea that building and releasing a minimal version lets you learn from real users before you've committed to a full build.
The three words break down simply. Minimum means the smallest set of features that still delivers value — not a demo, not a complete product, but the core. Viable means it actually works: real users can use it without hand-holding, and it doesn't break under normal conditions. Product means it functions — not a mockup or a slide deck, but something a user can interact with and get a result from.
When someone in software says "let's build an MVP," they mean: build the simplest version of this that works, put it in front of real users, and learn from how they use it before building anything else.
What "minimum" actually means
"Minimum" is where most proposals overdeliver — and most founders overbuy.
There are two ways to interpret the word: fewer features than the full vision, and as cheap as possible. These are not the same thing, and conflating them is how you end up with something that either costs more than expected or breaks the first time a real user touches it.
The right interpretation: minimum means you've scoped the product to the core user journey and nothing else. If someone is building a marketplace, minimum means a user can list something and buy something. Not a reviews system, not a loyalty program, not saved searches — the core flow only.
| Feature | Typically in scope? | Why |
|---|---|---|
| User sign-up and authentication | Yes | Required for any user action to be trackable or persistent |
| Core user flow (book, buy, post, search) | Yes | This is the thing you're testing |
| Basic error handling and data persistence | Yes | Required for the product to be viable — not a feature, a baseline |
| Payment processing | Case by case | In scope if payment is the core action; can be deferred if you're testing interest first |
| Email or push notifications | No | Add complexity without changing what you learn about the core concept |
| Admin dashboard | No | You can manage early data manually; build this once you have data worth managing |
| Social features (likes, shares, follows) | No | Post-MVP; only useful once you have an active user base |
| Advanced search and filters | No | Unless discovery is the core feature — most products don't need this at launch |
The wrong interpretation — minimum as in cheap — produces something that looks minimal but isn't production-ready. A minimum viable product still needs real infrastructure: user authentication, error handling, a database that doesn't corrupt data under load. These aren't optional extras. They're what makes the product viable.
What "viable" actually means
Viable is the word that justifies the cost.
A viable product handles real users doing real things. It doesn't require you to manually process actions behind the scenes. It doesn't fall over when two people sign up at the same time. It doesn't lose data between sessions. These aren't advanced features — they're baseline requirements for a product that can teach you anything useful.
This is why a properly built MVP costs real money. The $15,000–$60,000 range typical for a software MVP — our pricing guide gives a more specific breakdown by scope — isn't for the feature count. It's for the engineering underneath that makes those features reliable. A demo that costs $3,000 might look identical in a screenshot. It won't hold up when your first user tries to complete a real transaction.
The word "viable" also sets the bar for what you're learning. If your MVP breaks unreliably, every piece of user feedback becomes suspect. You can't tell whether people stopped using it because the concept didn't resonate, or because it was too buggy to bother with. Viable means the product gets out of the way and lets you learn about the idea, not about the implementation.
What an MVP is not
Several things get called MVPs in practice that aren't.
A prototype is a demo — it looks real, but nothing actually works. Clicking "Sign Up" on a prototype takes you to the next screen; it doesn't create a user account. Prototypes are useful for getting early feedback on a concept, but they can't tell you whether people will actually use your product.
A beta is a later stage. If your MVP is the first version that works, a beta is the version that works for a larger audience. Betas are more polished and feature-complete — you're testing scale and edge cases, not the core concept.
A side project is built to a lower standard because the stakes are lower. An MVP is built to production standards — real infrastructure, real security, real error handling — because it's meant to serve real users and generate real learning.
The distinction matters because what you call a thing shapes what you're willing to pay for it and what you expect from it. A prototype is a visual tool. An MVP is a working product. If you're being quoted for an MVP and what you're getting functions more like a prototype, that's worth understanding before you sign.
How to scope your MVP
The most practical definition of MVP scope: what is the one thing a user needs to be able to do for this product to be worth building?
Name that one thing. Then strip out everything that isn't required to complete it.
For a marketplace: a user can list something and purchase something. For a SaaS tool: a user can create an account and complete the core action. For a booking platform: a user can search, book, and receive confirmation.
Everything else — social features, notifications, dashboards, integrations — goes on the post-MVP list.
The honest reason founders overshoot MVP scope is that the features they're cutting feel essential from the inside. An email notification for a new booking feels like table stakes. But if you're testing whether people want to book at all, the notification doesn't change what you're learning. It adds complexity, time, and cost to a question you haven't answered yet.
One useful test: if this feature fails to work, does a user fail to complete the core action? If yes, it's probably in scope. If no, it probably isn't.
If you want to see what an MVP scope looks like for your specific idea, our free estimate tool gives you a real scope and price range in a few minutes — no call required.
What you scope into your MVP determines what you learn from it. Too many features, and you've built something expensive before validating the core question. The definition of MVP isn't a technicality — it's a decision about what you're willing to learn before you commit to more.
Questions, answered.
MVP stands for minimum viable product — the simplest version of your product that delivers enough value for real users to use it and give you meaningful feedback. The concept comes from Eric Ries' Lean Startup methodology, which argues that you learn more from a working product in users' hands than from months of planning.
A software MVP built by a professional development team costs between $15,000 and $60,000, depending on the complexity of the core flow and which integrations you scope in. Simpler products with one or two user actions sit at the lower end. Products with real-time features, third-party integrations, or payment processing sit toward the higher end.
A prototype is a demo — it looks real but nothing actually works. Clicking 'Sign Up' on a prototype takes you to the next screen; it doesn't create an account. An MVP is a functioning product that real users can use. Prototypes validate an idea visually; MVPs validate it with actual usage.
Most software MVPs take 6–12 weeks to build with a dedicated team. Simple products with a narrow core flow can be done in 4–6 weeks. Products with more integrations, an admin interface, or real-time components typically take 8–12 weeks.
Include only the features required to complete your product's core user action — the one thing a user needs to do to get value. If a feature doesn't prevent a user from completing that action, it belongs on the post-MVP list. Everything non-essential adds time, cost, and complexity before you've validated the thing you're actually testing.