“Start with an MVP” has become default advice, which is how it stopped being useful. An MVP is an instrument for reducing one specific kind of risk. If that is not the risk you have, building one costs you a quarter and teaches you nothing you did not already know.
The decision turns on a single question: what are you uncertain about?
Once you have decided, the MVP playbook covers executing the small version and the timeline guide covers the full one. Budget ranges for both are in what an iOS app costs.
The Question Underneath the Decision
There are two different uncertainties, and they call for opposite responses.
- Demand risk: will anyone use this? You do not know whether the problem is real, whether your solution fits it, or whether people will change their behaviour to adopt it. An MVP is exactly the right instrument.
- Execution risk: can we build this well enough? Demand is established. The open question is whether you can deliver something reliable, fast, and competitive. An MVP answers a question you already know the answer to and delays the one that matters.
Most teams can name which one they have in a sentence. The trouble starts when a team with execution risk builds an MVP because it is the accepted practice, then spends a quarter proving demand they had already proven.
Build an MVP When
- You have not validated demand with real behaviour. Survey enthusiasm and interview interest do not count; people using something they had to go and get does.
- The core workflow is genuinely novel. If nobody has solved this before, you are wrong about some of it, and you want to find out which part cheaply.
- You are pre-funding or pre-revenue. A 4-8 week build you can afford beats a six-month build you cannot finish.
- Your first users will tolerate rough edges: early adopters, internal staff, or a design partner who wants the outcome enough to put up with the path.
- The market could move under you. Shipping something in two months beats shipping everything in ten when a competitor or a platform change could make the plan obsolete.
Go Straight to a Full Build When
- Demand is proven. You have an existing product, a waiting list that converts, or signed contracts. Re-validating at that point is procrastination with a methodology.
- Your buyers judge on completeness. Enterprise procurement, healthcare, and financial services evaluate against requirement lists, and a partial product reads as unserious rather than early. You usually get one evaluation.
- The domain is regulated. Security, consent, audit trails, and data handling are not phase-two features; in many domains an incomplete implementation is not lawful to ship at all. The mobile banking security checklist is a good picture of how much of a regulated app is non-optional.
- Table stakes are high. In a mature category the minimum viable product is whatever competitors already offer, and there is no cheap version of that.
- Switching costs are high for users. If adoption means migrating data or changing a daily workflow, a thin product will not justify the switch, and you will misread the result as no demand.
The Failure Mode Nobody Plans For
The most expensive outcome is an MVP that succeeds without anyone having decided what happens next.
Usage grows, the team is pushed to add features, and the shortcuts that got the first version out in six weeks (no tests, no error handling, a data model built for one workflow) become permanent. Every feature after that is slower than the last. Eighteen months later the team is discussing a rewrite of an application that works.
Two commitments prevent this, and both have to be made before the MVP is built:
- Define the success threshold in advance. A number and a date. For example: by the end of week eight, 30% of invited users complete the core action at least twice. Without a rule like that, you will argue about interpretation instead of deciding.
- Budget the consolidation. If the MVP succeeds, the following period goes to tests, error handling, observability, and the data model you actually need, not to features. This is the commitment teams skip, and skipping it is what turns a successful MVP into technical debt.
Minimum Scope, Not Minimum Quality
An MVP constrains how much you build, never how well. This distinction is where most MVP advice goes wrong.
Legitimate to cut: secondary workflows, edge cases, admin tooling, the second platform, integrations, and polish.
Not legitimate to cut: authentication done correctly, a coherent data model, errors handled visibly, crash reporting, and the ability to ship a fix the same day.
The reason is simple. Code written to be thrown away is almost never thrown away. It becomes the foundation, and every shortcut in it is paid for again by everyone who works on it afterwards.
The Middle Path
The framing above is a binary, and most real decisions are not. There is a middle path for when you have demand risk on one part of the product and execution risk on the rest: build the foundation properly and the uncertain surface thinly.
Concretely, that means production-grade authentication, data model, and infrastructure (the parts you are confident about and would have to rebuild anyway) paired with a deliberately minimal version of the feature you are unsure anyone wants. Rigour goes where uncertainty is lowest, and experiments go where it is highest.
This fits a specific and common situation:
- An existing business adding a mobile channel, where the users are known but the mobile workflow is not
- A product with one proven workflow and one speculative one
- A regulated domain where the compliance surface is fixed but the user-facing feature set is open
Watch for the inverse. Teams routinely build the uncertain part carefully, because it is the interesting part, and rush the foundation. The result is a well-made feature nobody wanted, sitting on infrastructure that cannot carry the feature people turn out to want.
A Decision in Four Questions
- What am I uncertain about: demand, or execution?
- What does being wrong cost? Regulatory or reputational consequences argue against shipping partial.
- Who are the first hundred users, and what will they tolerate?
- If this works, what happens in the next quarter? No answer means the MVP has no exit.
Answer those honestly and the choice is usually obvious. The teams that struggle here are almost always the ones that have not written down what they are trying to find out.
