How to scope an MVP for startups

What an MVP actually is

A minimum viable product (MVP) is the smallest thing you can build to learn whether your solution moves the problem — tested with real users making real choices. The word people misread is minimum. They hear "a small version of the full product." That is wrong, and the error is expensive.

An MVP is not a scaled-down product. It is an experiment wearing the clothes of a product. Its job is to answer one risky question, and everything that does not help answer that question is not part of it, no matter how obviously useful it would be in the finished thing.

Keep two terms apart:

• A prototype proves something can be built. It answers an engineering question and can live in a demo.
• An MVP proves people want it once built. It answers a market question and must reach real users.

You often build a prototype on the way to an MVP. But a working prototype nobody chooses to use has proven your engineering and disproven nothing about your market.

Why "minimum" fights every instinct you have

The founder's instinct is to add. Each feature seems necessary, each one is a small effort, and each one delays the only thing that matters: contact with a real user. The result is the six-month MVP, which is not an MVP at all — it is a product built on unverified assumptions, and it delivers its verdict far too late to change course cheaply.

The discipline of an MVP is subtraction, and subtraction is uncomfortable because every cut feels like shipping something worse. It is. That is the trade. You ship something worse in order to learn something sooner. The teams that struggle are the ones who cannot tolerate putting an embarrassing thing in front of a user — so they polish, and delay, and learn nothing for two quarters.

Every feature has an opportunity cost

Subtraction is hard because founders price a feature by what it costs to build, not by what it costs to have built it. Build cost is legible — a week of engineering, a known amount of design time. Opportunity cost is the week of user contact you gave up to get it, and everything you would have learned in that week. The second number is almost always larger, and it never appears on the roadmap.

Prioritization frameworks exist to force that comparison into the open. They differ in mechanics, but the useful ones share a single move: they rank work by what it returns, not by how badly someone wants it. Score each candidate feature by the learning it produces per unit of effort, and the wishlist reorders itself. The items that felt essential — the settings screen, the second integration, the polished sign-up flow — tend to sink, because what they return is comfort, not knowledge.

Ranking only works when the units are small enough to rank. A vision stated as "build the dashboard" hides a dozen decisions inside one word. Break the epic into small user stories and each decision surfaces on its own line: export to CSV, filter by date, share a link. Now you can strike nine of them, because you can see them. "The dashboard" resists cutting precisely because you cannot see what is inside it. Granularity is what makes a cut possible at all.

Watch how the two prices diverge on a single item. The onboarding tour costs "three days" to build — that is the build price, and it sounds cheap. Its opportunity price is the three days of watching real users stumble through the raw product, which is exactly the friction the tour is meant to paper over. Build the tour and you have hidden the signal you most needed to see. The feature that looks cheapest to build is often the one whose opportunity cost is highest, because the thing it smooths over is the thing the MVP was supposed to measure.

This is the work AI does well and the judgment it cannot replace. It will draft the whole wishlist from your vision faster than a meeting can, and it will map each item to the assumption it tests without growing attached to any of them. What it cannot do is decide which assumption is worth your one week of build. Ranking is mechanical; choosing what to rank against is founder judgment, and it does not delegate.

Scope around the riskiest assumption

Every startup idea rests on a stack of assumptions. Some you can trust; some, if false, kill the whole thing. The MVP exists to test the second kind — specifically, the single riskiest one.

The riskiest assumption is the belief that, if it turns out to be false, makes everything else irrelevant. For a marketplace it is usually "supply will show up." For a productivity tool it is often "people will change their existing habit." For a paid service it is "they will pay rather than do it themselves." Name yours in one sentence, and scope the entire MVP to resolve it.

Then run every feature through one filter:

If the feature…	Then…
tests the riskiest assumption	it is in the MVP
tests an assumption you already trust	cut it
makes the product nicer but tests nothing	cut it
would be built the same way regardless of results	it is not part of the MVP

That last row is the sharpest test. If you would build the feature identically whether users love or hate the MVP, it is teaching you nothing right now. It can wait.

Discovery and delivery are different jobs

Building a product is two jobs that look alike and are not. Delivery is building the thing well — shipping it reliable, usable, maintainable. Discovery is finding out whether the thing is worth building at all. They reward opposite instincts, and the MVP is a discovery instrument. Treating it as a delivery job is the most common way founders lose a quarter.

	Discovery	Delivery
The question	Should we build this?	Does it work well?
Rewards	Speed, disposability	Care, reliability
Standard of care	Just enough to learn	Production-grade
The MVP lives here	Yes	Not yet

When you polish an MVP, you are doing delivery work on something you have not yet decided is worth delivering. The concierge version — humans doing by hand what code will later do — is pure discovery: nothing built to last, everything built to learn. You earn the right to do delivery work only after discovery says yes.

Stage-gates make the boundary explicit. A stage-gate is a checkpoint between discovery and delivery where you decide, on evidence, whether the idea proceeds. Nothing crosses on enthusiasm alone; it crosses because the MVP returned a result above the line you set in advance. The gate is what stops a promising demo from sliding straight into a full build before anyone has confirmed there is demand for it.

Keeping the jobs separate also protects your engineers. Ask a delivery-minded team to build a throwaway concierge flow and they will, correctly, want to build it properly — tests, error handling, a real database. That instinct is right for delivery and wrong for discovery, where the whole point is that most of what you build gets thrown away. Name which job you are doing before you start, so the standard of care matches the stakes.

Ship output, but measure outcome

A shipped feature is an output. A changed user behavior is an outcome. The distinction is easy to nod at and hard to live by, because output is visible and outcome is not. You can see the feature merge. You cannot see, without looking for it, whether anyone's behavior changed because of it.

The six-month MVP is an output machine. It measures progress in features shipped, and by that measure it is winning right up to the launch where it discovers nobody wanted the thing. An MVP scoped around a risky assumption measures the opposite: not "did we ship it" but "did the user do the thing that proves the assumption." Return visits. The core action completed. Money that actually moved. Those are outcomes, and they are the only readings that count.

This is why the MVP needs a small amount of instrumentation from the first user, not the tenth. You do not need the analytics a mature company would recognize; you need to know whether the single behavior your assumption predicts is actually happening. Decide, before launch, the one or two events you will watch, and make sure the MVP records them. An experiment you cannot read is not an experiment.

Treat each MVP as one experiment with one prediction: state what users will do if the assumption holds, then watch whether they do it. A concierge flow makes this easier, not harder — when a human runs the process, that human sees every hesitation, every question, every drop-off directly, before there is any dashboard for the truth to hide behind.

Fake what you have not built: the concierge MVP

The fastest MVP often has almost no software in it. A concierge MVP delivers the real outcome to real users by hand — humans doing manually what the product will later automate. The user gets the genuine result; you get evidence of demand at a fraction of the build cost.

If your product will one day generate a report, generate the first ten reports yourself in a spreadsheet and deliver them. If it will match buyers and sellers, do the matching over email. The user does not care that the back end is a person. They care whether the outcome is worth having.

The concierge approach buys you three things:

• Speed — days to first learning instead of months.
• Flexibility — you can change the "product" between every user because there is no code to refactor.
• Honest demand data — people either come back for the manual outcome or they do not, and that is the signal you actually need.

The concierge plan records the manual process, who runs it, and — critically — the threshold at which manual effort should be replaced by software. Concierge is a starting line, not a business model. You automate once demand is proven, not before.

Build, buy, or fake

For every capability the MVP seems to need, you have three options, and building is usually the worst of them. You can build it, buy it (an off-the-shelf tool, a no-code stack, an existing service), or fake it (do it by hand, concierge-style). Founders reach for build first out of habit, because building feels like progress. It is the slowest and most expensive way to answer a question that buying or faking would answer this week.

The rule during discovery is to build as little as possible. If a payment can run through an existing checkout link, use it — do not build billing. If a workflow can live in a spreadsheet and a shared inbox, let it — do not build an app. Every component you buy or fake is a component you do not have to maintain, refactor, or explain later when the assumption turns out to be wrong. You reserve building for the one thing the MVP exists to test — the part where no off-the-shelf tool and no manual workaround can stand in, because that part is the actual bet.

Build-versus-buy becomes an engineering question only after the assumption holds. Before that, "should we build this?" almost always has the same answer: not yet. The discipline of the MVP is to keep the built surface as small as the experiment allows, so that when the verdict comes back — hold or fail — you have the least possible code invested in a bet that might not have paid.

Set the success threshold before you launch

An experiment without a pass mark is not an experiment; it is a demo you will interpret generously after the fact. Before the MVP reaches anyone, write down what result would count as success — the number of users who return, complete the core action, or agree to pay.

Then commit to the decision each outcome triggers:

1. Above the threshold — the assumption holds. Build the next-riskiest piece.
2. Near the threshold — mixed. Adjust the MVP and re-run, do not expand it.
3. Below the threshold — the assumption failed. Pivot the approach before adding anything.

Writing the threshold down in advance is what stops you from moving the goalposts. It is easy, after weeks of work, to decide that a weak result is "actually encouraging." The pre-committed number is the thing that argues back.

Keep a "don't do" list, then sequence the next bet

When the MVP clears its threshold, the pressure reverses. Now everything you cut wants back in, and it arrives wearing the authority of a validated idea. Resist it the same way you scoped in the first place: one riskiest assumption at a time.

Two artifacts keep the sequence honest.

The first is a "don't do" list — the features you deliberately cut, written down where you will see them again. A prioritized backlog tells you what to build next; the don't-do list tells you what you already decided not to, and why. Without it, every cut feature returns next week as a fresh idea and you re-litigate the same call until something ships out of exhaustion rather than conviction.

The second is a rough horizon — now, next, later — that holds no more than it can defend. Now is the assumption you are testing this cycle. Next is the one you will test if this clears. Later is everything else, held loosely and unpromised. The value is not the plan itself; a plan built on unvalidated assumptions is fiction. The value is that "later" is an honest place to put a good idea so it stops arguing for a seat in "now."

Each cycle repeats the same loop: name the next-riskiest assumption, scope the smallest test, set the threshold, read the result, decide. The MVP is not a phase you finish and leave behind. It is the first turn of a discipline you keep running until the product's core bets are no longer bets.

The output: a scoped MVP and a concierge plan

Scoping ends in two artifacts. The scoped MVP names the single assumption under test, the minimum you will build, the success threshold, and the decision each outcome triggers. The concierge plan names what you will fake by hand, who runs it, and when manual work gives way to code.

Together they are a contract with your future self: this is the one thing we are trying to learn, this is the least we can build to learn it, and this is what each result means. An MVP without that contract expands quietly into a product — and a product built to answer no particular question is the most expensive way to discover you were wrong.