“Start with an MVP” has become default advice, which is how it stopped being useful. An MVP is an instrument for reducing a specific kind of risk. If that is not the risk you have, building one costs you time and teaches you nothing.
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 fundamentally 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 behaviour to adopt it. An MVP is exactly the right instrument.
- Execution risk — can we build this well enough? Demand is established. The question is whether you can deliver something reliable, performant, and competitive. An MVP answers a question you already know the answer to, and delays the one that matters.
Most teams can name which they have in one 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 are not evidence. Usage is.
- The core workflow is genuinely novel. If nobody has solved this, you are wrong about some of it and you want to be wrong cheaply.
- You are pre-funding or pre-revenue. Capital constraints make the cheap experiment the only responsible option.
- Your first users will tolerate rough edges. Early adopters, internal users, or a design partner who wants the outcome enough to endure the path.
- The market could move under you. Shipping something in ten weeks beats shipping everything in forty when the landscape is shifting.
Go Straight to a Full Build When
- Demand is proven. You have an existing product, a waiting list that converts, or contracts. Re-validating is procrastination.
- Your buyers judge on completeness. Enterprise procurement, healthcare, and financial services evaluate against requirement lists. A partial product does not read as “early” — it reads as unserious, and 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.
- Table stakes are high. In a mature category, the minimum viable product is whatever competitors already offer. There is no cheap version of that.
- Switching costs are high for users. If adoption means migrating data or changing a 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 not choosing wrong. It is an MVP that succeeds without anyone having decided what happens next.
Usage grows, the team is under pressure to add features, and the shortcuts taken to ship in ten weeks — no tests, no error handling, a data model built for one workflow — become permanent. Every subsequent feature is slower than the last. Eighteen months later the team is discussing a rewrite of an application that is working.
Two commitments prevent this, and both must be made before the MVP is built:
- Define the success threshold in advance. A number and a date. Without it you will argue about interpretation instead of deciding.
- Budget the consolidation. If the MVP succeeds, the following period is for tests, error handling, observability, and the data model you actually need — not 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: workflows, edge cases, admin tooling, platforms, integrations, polish.
Not legitimate to cut: authentication done correctly, data modelled coherently, 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 is paid for repeatedly by everyone who works on it afterwards.
The Third Option Nobody Names
The framing above is a binary, and most real decisions are not. There is a middle path that works 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. You are not shipping a lesser product; you are allocating rigour where uncertainty is lowest.
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 non-negotiable but the user-facing feature set is open
The failure mode to watch is the inverse: teams routinely build the uncertain part carefully — because it is the interesting part — and rush the foundation. That produces a beautiful feature nobody wanted, sitting on infrastructure that cannot carry the feature they discover people actually 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 actually trying to find out.
