MVPs fail for nine reasons, and engineering is near the bottom of the list. In order of frequency: the problem was never validated, the scope was a full product with a smaller name, nothing was measured, the first session confused users, the founder stopped at launch, the product was built for the wrong user, decisions took too long, the team was chosen on price, and the technology could not change. Each has a fix, and most of the fixes happen before the build starts.
Most MVPs do not fail dramatically. They launch, get some sign-ups, drift, and are quietly abandoned eight months later with the founder unsure what went wrong. Having built MVPs for years and inherited many built by others, we see the same nine causes again and again. They are listed here in the order we see them, with the fix for each. If you recognise your own plan in the first three, stop and fix it before you spend.
1. The problem was never validated
What it looks like: a product built from the founder's conviction, with no interviews, no waiting list, no pre-sale. Launched to silence.
The fix: twenty conversations with strangers who should have the problem, a landing page with a waiting list, a concierge version done by hand. Build only when strangers take a costly action. How to validate a startup idea before writing code is the method.
2. The scope was a full product with a smaller name
What it looks like: fifteen features, three user roles, iOS and Android and web, nine months, the whole budget. Called an MVP in the pitch deck.
The fix: three to six features, one user type, one platform. Score every feature on whether it is needed for the core journey, whether it tests something, and whether it can be faked. How to scope an MVP walks through it.
3. Nothing was measured
What it looks like: the product launched without analytics on the core journey. Three months later nobody knows whether users activated, where they dropped off or whether they came back. The MVP cannot answer the question it was built to ask.
The fix: event analytics on every step of the core journey, retention tracking and error monitoring, wired in during the build and checked before launch. Which metrics to track after launch names the five numbers.
4. The first session confused users
What it looks like: the idea is sound, the users arrive, and most leave inside two minutes because they could not work out what to do. The founder concludes the idea failed.
The fix: a clickable prototype tested with ten target users before development starts, and session recordings watched in the first week after launch. Path problems are the cheapest to fix and the most often mistaken for value problems. How to test an MVP with real users covers both.
5. The founder stopped at launch
What it looks like: launch day, a burst of effort, then the team is released and the founder goes back to the day job or on to fundraising. Bugs sit for weeks. Users who wrote in never hear back. Version two never ships.
The fix: treat launch as the start. Keep the team on a lighter cadence for 90 days, interview users, write a decision memo at week seven, ship a small version two by week twelve. What to do after your MVP launches is the plan.
6. It was built for the wrong user
What it looks like: the product serves everyone who might have the problem, and therefore nobody well. Or it serves the user the founder imagined, while the people who actually retain are a different segment that the product half-fits.
The fix: one user type, specific enough to find ten of them this week. After launch, look at who retains, and if it is not who you planned for, narrow to them. The segment that retains is the business.
7. Decisions took too long
What it looks like: designs waiting two weeks for approval, demos unanswered, content arriving a month late. A twelve-week build becomes twenty-four, the budget is spent on waiting, and the market has moved.
The fix: one decision maker who answers within a day, a weekly call that never slips, and content ready before the build needs it. How long an MVP takes shows how much time this costs.
8. The team was chosen on price
What it looks like: the lowest quote, which was for the smallest reading of the scope. Discovery skipped, design templated, testing left to the founder. The product ships late, with the missing parts billed as changes, and needs rebuilding within a year.
The fix: compare written scopes and exclusions, not headline prices. Check that the team has shipped MVPs, not just features. How to choose an MVP development company has the checklist, and what a fixed-price MVP package should include shows what cheap packages cut.
9. The technology could not change
What it looks like: the one engineering failure on the list. A no-code platform hit its limits, or the code was built so quickly that every change breaks something, or the stack was so unusual that nobody can be hired to work on it. The MVP learned what to do next and could not do it.
The fix: a mainstream stack, a sensible data model, code in your repository, and a short technical review of the codebase before launch. Choosing a tech stack for an MVP explains the choices that are hard to reverse.
Which mistakes happen when?
| Mistake | When it is made | When it is discovered | Cost to fix then |
|---|---|---|---|
| 1. Not validated | Before the build | After launch | The whole build |
| 2. Over-scoped | Before the build | Month six | Months and most of the budget |
| 3. Not measured | During the build | Three months after launch | Three months of learning |
| 4. Confusing first session | Design | Week one after launch | A few weeks of polish, if caught |
| 5. Stopped at launch | Launch | Month four | Often the company |
| 6. Wrong user | Before the build | After launch | A pivot |
| 7. Slow decisions | Throughout | Every week | Weeks per decision |
| 8. Chosen on price | Hiring | Mid-build | Change requests, then a rebuild |
| 9. Technology cannot change | Build | Version two | A rebuild |
Six of the nine are decided before a line of code is written. That is the point. The MVPs that fail usually failed in discovery, and the build just made it visible. Why startups fail and why apps fail after launch cover the wider patterns.
The pre-build checklist
- Strangers have taken a costly action for the problem.
- Three to six features, one user, one platform, written down.
- Analytics in the scope, not after.
- Prototype tested with ten target users.
- A 90-day post-launch plan and budget.
- One decision maker, a weekly call.
- A team chosen on scope and track record.
- A mainstream stack and your own repository.
How 7L avoids the nine
Our discovery phase exists to catch the first, second and sixth before any money is spent on the build, and we have told founders not to build yet when the evidence said so. Analytics, prototype testing and a post-launch period are in every MVP we scope. The seventh is the one we cannot fix for a founder, and we say so at the start. If you have an MVP that is drifting and want to know which of the nine it is, describe where it is and we will tell you.
Frequently asked questions
What percentage of MVPs fail?
Most, by the measure of the product not reaching a sustainable version two. But an MVP that proves the idea is wrong cheaply has done its job. The failures that matter are the ones that never answered the question, because they were not measured, not validated or never followed through.
Is a failed MVP a failed startup?
No. An MVP that shows the product is not wanted, for a tenth of the cost of a full build, is a success of method. Many good companies pivoted after a first MVP. The failure is spending the full budget on a full product to learn the same thing.
Which of the nine is most common?
Not validating the problem, by a distance. It is the easiest to avoid and the most expensive to discover late. The second most common is scoping a full product and calling it an MVP, which usually follows from the first.
Can a good development team prevent these failures?
Six of the nine, if the team runs a real discovery phase and the founder listens. A team cannot fix slow decisions, an absent founder after launch, or a founder who insists on building before validating. Choose a team that pushes back, and let them.
My MVP launched and the numbers are poor. Is it too late?
Usually not. Sort what you know into path problems and value problems. Path problems are fixable in weeks. Value problems need a pivot to the segment or the use that did work. Our post on what to do after your MVP launches maps the patterns to the decisions.