How long should it take to build an MVP?

It depends on the test, but the bias should be toward days and weeks, not months. A landing page or concierge test can run in a few days. If a software build is genuinely needed, aim for roughly two weeks of focused work on the single path that exercises your riskiest assumption. A multi-month build usually means you're testing too many assumptions at once.

What is the difference between an MVP and a prototype?

A prototype is a model you use to explore or demonstrate how something could work, often internally. An MVP is a live experiment put in front of real users to learn whether your riskiest assumption is true, measured by actual behavior like sign-ups, payments, or repeat usage. A prototype answers 'can we build it,' an MVP answers 'should we.'

Does an MVP have to be an app or software?

No, and often it shouldn't be. Landing pages, concierge MVPs where you deliver the service manually, and Wizard of Oz MVPs where a human runs the experience behind the scenes can validate demand, value, or the user experience faster and cheaper than code. Build software only when no lighter test can answer the question.

How do I know if my MVP succeeded?

Decide the pass/fail threshold before you launch, tie it to a behavior rather than an opinion, and test on strangers who actually have the problem. If real users hit the threshold you set in advance, that's a pass. If you find yourself rewriting the threshold after seeing the data, the honest answer is probably no.

What is the riskiest assumption test?

It's the practice of listing every assumption your idea depends on, scoring each by how uncertain and how fatal it is, and aiming your first MVP at the one that is both most uncertain and most damaging if wrong. Testing the riskiest assumption first means you fail or validate cheaply instead of building a polished product on a broken belief.

How to Build an MVP That Tests Your Riskiest Assumption

What an MVP Actually Is (and What It Isn't)

Most founders treat the minimum viable product as a stripped-down version 1.0: same vision, fewer features, ship it and pray. That framing is the trap. An MVP is not a small product. It is an experiment. Its job is to buy you the maximum amount of validated learning for the least amount of build time and money.

The word that gets ignored is viable. Viable doesn't mean polished, it means the test is real enough to produce a believable yes or no. If your MVP can't change your mind, it isn't an MVP, it's just slow product development with extra steps.

Here's the reframe that matters: before you write a line of code, ask what single belief your entire business depends on. If that belief is wrong, no amount of UI polish, onboarding, or pricing tweaks will save you. That belief is your riskiest assumption, and your first MVP exists to test it and nothing else.

How to Find Your Riskiest Assumption

Every startup idea is a stack of assumptions wearing a trench coat. A meal-kit-for-dogs idea quietly assumes: dog owners are unhappy with current food, they'll pay a premium, they'll trust a new brand with their pet's health, the unit economics work after shipping refrigerated boxes, and you can acquire customers cheaply. Each of those can be true or fatal.

To find the riskiest one, list every assumption your idea requires, then score each on two axes: how uncertain you are that it's true, and how much damage it does if it's false. The assumption that is both highly uncertain and highly fatal is where you start. This is the Riskiest Assumption Test, and it's the discipline most MVPs skip.

Founders almost always default to testing the assumption they're most excited to build, usually a feature, when the truly risky belief is something boring like 'people will actually pay for this' or 'we can reach these customers at a sane cost.' If you find yourself eager to build, that's a signal to stop and ask whether you're testing risk or just avoiding it.

Turn the Assumption Into a Falsifiable Hypothesis

A riskiest assumption you can't fail is useless. Before building, rewrite it as a specific, falsifiable hypothesis with a number attached. 'People want this' is not testable. 'At least 15 of the 50 freelance designers I email will pre-pay a $20 deposit for early access within one week' is testable, because it can be wrong.

Three parts make a hypothesis usable: the behavior you expect, the population you're testing on, and the threshold that counts as a pass. Decide the threshold in advance. If you set the bar after seeing the results, you'll always find a story that says you succeeded, which is how dead ideas survive for years.

This is exactly the moment a brutally honest outside read helps. A tool like PitchRoast is built to poke holes in your pitch and surface the assumption you're quietly hoping nobody checks, so you point your MVP at the real risk instead of a comfortable one. The goal isn't to feel good, it's to fail cheap.

Choose the Cheapest MVP That Answers the Question

Once you know what you're testing, pick the lightest format that can produce a real answer. The classic ladder, roughly cheapest to most expensive: a smoke-test landing page, a concierge MVP, a Wizard of Oz MVP, and only then a single-feature build.

A landing page MVP tests demand: describe the offer, add a real call to action like a waitlist or a pre-order, drive a small amount of traffic, and measure conversion. A concierge MVP tests whether the outcome is valuable by delivering it manually, no software, you do the work by hand for your first few users. A Wizard of Oz MVP looks automated to the user but a human is behind the curtain doing the work, which lets you test the experience before building the engine.

The famous example is the founders who tested a shoe-buying idea by photographing shoes in local stores and posting them online, buying the pair at retail only when someone actually ordered. That test answered 'will people buy shoes online without trying them on' for almost no money, before any inventory or logistics existed. Match the method to the question: demand, value, or experience.

Scope the Build: One Assumption, One Metric

If your test genuinely requires building software, ruthlessly cut scope to the one path that exercises your riskiest assumption. Everything else, accounts, settings, edge cases, that beautiful dashboard, is a distraction until the core belief is validated. A common rule of thumb is to keep the first build to a couple of weeks of work, because a long build is usually a sign you're testing too many things at once.

Define your single success metric before you start, and make it a behavior, not a feeling. Sign-ups, pre-payments, repeat usage, and referrals are behaviors. 'They said they loved it' is a feeling, and feelings are free to give away. People are kind in interviews and honest with their wallets and their time.

Instrument the one thing you care about so you can actually see whether the threshold was hit. You don't need a full analytics stack on day one, you need to reliably count the single action that proves or disproves the hypothesis.

Ship, Measure, and Decide: Persevere, Pivot, or Kill

Get the MVP in front of real people who match your target population, not friends, not your launch-day cheerleaders. Friends and supporters will inflate every number you care about and teach you nothing. You want strangers who have the problem and a real reason to act.

When the results come in, compare them against the threshold you set earlier and make one of three calls. Persevere if you cleared the bar and the assumption holds, then move to the next riskiest assumption with a new test. Pivot if the data points to a different, more promising direction. Kill, or at least pause, if the riskiest assumption fails clearly, because killing a wrong idea fast is a win, it returns your most finite asset: time.

The hardest part isn't building the MVP, it's honoring the result when it isn't what you wanted. The founders who win aren't the ones who never built the wrong thing, they're the ones who found out cheaply and moved on. An MVP is how you buy that speed.