The term MVP has become so widely used that it has largely lost its meaning. When founders say they are building an MVP, they often mean one of three very different things: a prototype that cannot be deployed, a full product that took a year to build, or a stripped-down version of the full vision that still took six months and $60,000.
None of these is an MVP in the original sense. And all three fail at approximately the same rate, which is high.
The failure is not usually a bad idea. Most of the ideas that become failed MVPs had genuine merit. The failure is execution: wrong scope, wrong team, wrong process, or all three.
Why they fail
Wrong scope (too large). The most common failure mode. The founder describes a vision. The development team estimates the vision. The budget and timeline balloon. Everyone feels committed to the full thing. Halfway through, the money runs low, the timeline has expanded by 40%, and the product is still not working end to end. The project either launches in a broken state or never launches at all.
Wrong scope (too small). The opposite failure. The founder, having read about lean startups, builds something so stripped down that it cannot actually demonstrate value. A landing page with a form is not an MVP. A mockup is not an MVP. A partially functional prototype that cannot be meaningfully used is not an MVP. When these "MVPs" fail to generate engagement, founders conclude the idea was wrong when the product was simply not functional enough to test anything.
Wrong technical partner. The team did not have the right experience for the specific type of product being built. Or they were too cheap and the code quality was poor. Or they over-engineered a simple product. Or they changed key personnel mid-project. Or they did not do discovery and started building from an ambiguous brief.
Wrong founder engagement. The founder handed the project over to the development team and checked in at the end. Developers made hundreds of small decisions that did not reflect what the founder actually wanted. The delivered product was what was asked for, not what was needed.
The 3 things that actually work
1. Ruthless scope reduction based on a single critical path
Before any code is written, identify the single path from "new user signs up" to "user receives the core value." Draw it out step by step. Every step that is not on this path is post-MVP.
This sounds simple. It is not. The instinct to include is powerful. Every team member and every stakeholder will have ideas for things to add. The discipline of subtraction is what separates MVPs that launch from MVPs that never finish.
A useful test: for every feature in the scope, ask "Can the user complete the critical path without this?" If yes, it is out. If no, it stays.
The critical path for an invoicing tool: sign up, create client, log time, generate invoice, send invoice. The rest, payment processing, multi-currency, team collaboration, reports, is post-MVP.
2. A real discovery phase before writing a line of code
Discovery produces three to four weeks of output before development begins:
- A written scope document with acceptance criteria for each feature
- Wireframes of every screen in the critical path
- Technical architecture decisions documented and agreed
- An estimate with meaningful confidence because the team actually knows what they are building
The discovery phase costs money. Typically $3,000-$8,000 with a good team. It saves the following: at minimum one full week of rework that would have resulted from misunderstood requirements. Usually three to four weeks. Sometimes the whole project.
Founders who skip discovery to save money almost always spend more money by the time the project is done.
3. Weekly working demos, not end-of-project delivery
The founders who are most surprised by a bad delivery are the ones who saw working software for the first time at the end of the project.
Require a working demo at the end of every two-week sprint. The demo does not need to be polished. It needs to show what was built, running live, with real data. This does the following:
- Surfaces misalignments between what was specified and what was built while changes are cheap
- Keeps the development team accountable to weekly delivery, not just a distant deadline
- Gives the founder frequent visibility into what is actually happening
- Builds momentum for both sides as working software accumulates
A development team that will not show you working software every two weeks is a team that either does not have working software or does not want you to see it. Neither is acceptable.
What an MVP is supposed to do
The MVP is not supposed to be your product. It is supposed to be a question: "Will this approach work?"
The question is answered by getting the MVP in front of real users, watching what they do, asking what they think, and adjusting. Most MVPs that "fail to gain traction" never actually got in front of enough real users to learn anything. They were shown to a handful of friendly contacts who were polite and then the founder concluded the market was too small.
A real market test requires reaching people who do not know you, are not doing you a favour, and have no reason to use your product other than the fact that it solves their problem. Getting to those people is harder than building the software.
The cost of doing it right
A well-scoped, well-executed MVP for a straightforward SaaS tool costs $20,000-$40,000 using an experienced offshore development team. A complex product with significant integrations costs $40,000-$80,000.
A mis-scoped, under-specified MVP that goes through three rounds of rework costs the same or more and delivers less.
Use our MVP cost calculator to scope your project before talking to any development team. Arrive with a clear idea of what you are building and you will get a much more accurate estimate, faster, from anyone you speak to.
Then talk to our team. We have a structured process specifically for early-stage founders who want their first product built efficiently and correctly.