How to build an MVP that actually proves something

The term "minimum viable product" has been diluted to mean "version one", which is why so many MVPs take nine months and prove nothing. In the Incubate stage of our process, an MVP has a narrower job: to produce evidence about a specific uncertainty at the lowest cost and in the shortest time that will still give an honest answer.

Start with the question, not the backlog

Before any scoping, write the question the MVP exists to answer. It should be uncomfortable, specific and falsifiable. "Will operations managers in mid-sized logistics firms use a daily exception report enough to pay for it?" is a question. "Will people like our product?" is not.

Then write the answer that would stop the venture. Teams that skip this step reliably reinterpret weak results as encouragement. Deciding the failure condition in advance is the difference between an experiment and a launch with a defensive name.

Choosing the right kind of MVP

The concierge approach — delivering the outcome manually behind a simple interface — is consistently under-used. It answers demand questions in weeks rather than quarters and produces something automation cannot: a precise understanding of the work being automated.

Building it

MVPs are built in short cycles with real users involved throughout — the discipline is agile in substance rather than ceremony. Two practical rules matter more than any methodology. First, put it in front of real users weekly, even when it embarrasses you. Second, keep the architecture reversible: an MVP is allowed to accrue technical debt, provided the debt is documented and the decisions that would be expensive to undo are taken deliberately.

The architecture decisions worth taking properly at this point are data model, integration boundaries and anything touching security or customer data. Everything else can be rewritten later, and often should be.

Reading the result honestly

Three outcomes are possible, and only one of them is a green light. The evidence supports the question and the venture proceeds towards Launch. The evidence contradicts it, and the venture changes or stops — cheaply. Or the evidence is ambiguous, which almost always means the question was too broad or the sample too small, and the correct response is another short cycle rather than a larger build.

This is also where staged funding earns its keep. Money released against evidence rather than optimism keeps the cost of being wrong proportionate — the argument we make in capital alone doesn't build great companies.

The next question after a positive MVP is not "what features next?" but "do we have product-market fit?" — a harder question, addressed in what product-market fit actually looks like.

What to measure while the MVP is live

Most MVPs are instrumented after launch, by which point the early behaviour that would have been most informative has already happened and gone unrecorded. Decide the measures alongside the question. For a demand test, that usually means activation, repeat use within a defined window, and the specific action that represents value being received rather than curiosity being satisfied. For a feasibility test it means unit cost and time to deliver. Vanity measures — registrations, page views, positive comments — should be recorded but never used to make the decision.

How long an MVP should take

Our working expectation in Incubate is weeks rather than quarters, funded deliberately at a level that matches the size of the question — typically a small pre-seed round rather than an open-ended budget. The constraint is not a preference for frugality; it is that a long build changes what is being tested. After nine months the team is no longer testing a hypothesis, it is defending an investment, and the reading of the result changes accordingly.

Where a build genuinely cannot be compressed — deep technical work, integrations with slow-moving counterparties, regulated data — split the question. There is almost always a demand question that can be answered in weeks while the feasibility work proceeds in parallel, and answering it first protects the larger spend.