“MVP” is probably the most abused term in startup vocabulary. Founders use it to mean everything from a napkin sketch to a fully featured product that just hasn’t launched yet. The confusion is expensive — projects run over budget, over time, and often deliver something that still doesn’t answer the core question the MVP was supposed to answer.
This is what an MVP actually is, how to scope one that works, and what it realistically costs to build.
What an MVP Is (and Isn’t)
The Minimum Viable Product, as Eric Ries defined it in The Lean Startup, is the smallest thing you can build that delivers enough value to a specific set of users to generate real feedback. The key word is viable — it has to actually work for someone, not just technically function.
What it is not:
- A prototype (which doesn’t need to be production-quality)
- A beta version of your full product (which has too many features)
- Something you’re embarrassed to show people (if you’re not embarrassed, it’s probably not minimal enough)
The purpose of an MVP is to test a specific hypothesis: that this group of people has this problem badly enough to pay for this solution. Everything in the MVP should serve that test. Everything else is waste.
The Hardest Part: Deciding What’s Not in It
Most founders approach MVP scoping by listing features and trying to cut the list down. This produces MVPs that are still too big because founders anchor on what they want to build rather than on what’s necessary to test the hypothesis.
A better approach: work backward from the core value.
Ask: what is the single thing a user needs to do to get value from this product? Build that, and only that, first.
StatementPro’s hypothesis was: “People who need to import bank data into accounting software will pay for a tool that converts PDF bank statements to CSV instead of manually re-entering data.” The MVP needed to do exactly one thing — take a PDF in and produce a clean CSV out. It didn’t need a dashboard, a history view, multi-bank support, or a team plan. It needed to do one thing reliably for one bank.
Everything else came after the hypothesis was confirmed by paying customers.
A Framework for MVP Scoping
Go through every proposed feature and ask three questions:
1. Does a user fail to get the core value without this? If the answer is no, it’s not in the MVP. A notification system, a settings page with branding options, a public API — none of these are necessary to deliver the core value of most products.
2. Can this be done manually instead? Many features that seem necessary can be replaced temporarily by a human doing it manually behind the scenes. If you’re building a matching platform, you don’t need an algorithm in the MVP — you can match manually and learn what “good” looks like before you automate it.
3. Will we learn anything from building this? Every feature in the MVP should either deliver core value or teach you something specific. If a feature does neither, it shouldn’t be there.
What an MVP Costs in 2026
MVP costs vary significantly based on complexity, but here are realistic ranges for a professional development team:
Simple MVP (one user type, single core workflow, no integrations): $20,000–$50,000, 6–10 weeks
Mid-complexity MVP (two user roles, one or two integrations, basic admin): $50,000–$100,000, 10–16 weeks
Complex MVP (multi-tenant, heavy integrations, real-time features): $100,000–$200,000, 4–6 months
These assume a US-based team. Offshore development can reduce costs by 40–60% with appropriate quality and communication management.
The most common reason MVPs cost more than expected: scope that grows during the build. A feature that’s “already in the design” or “only a small addition” can add weeks when you account for the full development cycle — implementation, edge cases, testing, deployment, and the inevitable follow-on changes. Lock scope before you start. Changes mid-build are the most expensive kind.
The Mistakes That Kill MVPs
Building for the investor deck, not the user. Some features get built because they look impressive in demos or make the product feel more complete for fundraising. These features delay the real test. Build for your first customer, not your first investor.
Solving the problem too well. A product that handles every edge case, every user type, and every workflow variation before launch isn’t an MVP — it’s a v1.0. The goal is to solve the problem for ten users, not ten thousand. You’ll learn what “solving it well” means from those ten.
Not charging. A free MVP doesn’t tell you whether people will pay. It tells you whether people will use something free. Those are completely different signals. Charge from day one, even if the price is a discounted pilot rate.
Treating “shipped” as the end. The MVP isn’t done when it launches — it’s done when it has confirmed or refuted its hypothesis. Most founders underinvest in the feedback loop: talking to users, watching them use the product, understanding where it breaks down. The build is 50% of the MVP. The learning is the other 50%.
When to Stop Building and Start Talking
The single most underrated MVP activity is talking to the people who are supposed to want your product before you build it. Not a survey — actual conversations where you ask about their workflow, their current tools, their frustrations, and what they’ve already tried.
These conversations will do one of three things: confirm you’re building the right thing, help you refocus on a better version of the idea, or save you from building something nobody wants. All three outcomes are valuable.
Build the MVP only after you’ve talked to at least ten potential users and at least five of them have said something that sounds like “I’d pay for that today.”
We’ve built six MVPs for our own products and work with founders to scope and build theirs. If you want a straightforward assessment of what your MVP needs to include and what it will cost, get in touch.