How to test an MVP before you build it

An MVP is a test, not a small product

The point of a minimum viable product is to buy information about demand at the lowest possible price. A stripped-down version of your full app is usually the most expensive way to buy that information, because it still requires building.

Before you write code, write the claim you are testing and the number that would falsify it. 'Independent physios will pay $40/month to stop phone rebooking; the test fails if fewer than 5 of 50 contacted book a paid pilot.' Without a threshold set in advance, every outcome gets interpreted as encouraging.

Six experiments, cheapest first

1. Landing page with a price. One page stating the problem, the outcome, the actual price and a single call to action. Drive 100–300 targeted visits from the community or search term where your buyer already is. Pass: a signup rate you decided beforehand — typically 3–8% of qualified traffic leaving an email, or any paid pre-order at all.

2. Fake door. Add the button before the feature exists; on click, explain it is in development and offer early access. Measures intent inside real usage rather than in a survey. Only ethical if you tell the truth on the click and follow up.

3. Concierge. Deliver the outcome entirely by hand for 3–5 paying customers. You learn the real workflow, the real support burden and the real price tolerance. Pass: they keep paying for a second cycle.

4. Manual back end (Wizard of Oz). The customer sees an automated product; behind it you are doing the work in a spreadsheet. Best when the interface is the value and the automation is merely expensive.

5. Paid pilot / letter of intent. For B2B, a signed pilot with a start date and an invoice is worth more than a hundred landing-page emails. Pass: money or a signature, never verbal interest.

6. Single-workflow build. Only after one of the above passes: build one workflow end to end for one segment, and refuse every adjacent feature request until that workflow retains users.

Costing the test properly

Budget the experiment in days and currency before starting: page build, traffic spend, your own hours in concierge delivery, any tools. If a test costs more than 5% of the build it replaces, simplify it.

Count the delivery cost per customer during concierge, because it is the only honest early read on your unit economics. Many validated problems die here — the customer will pay $40 and serving them costs $70.

Reading the result without lying to yourself

Compare against the threshold you set in advance, not against your hopes on the day. Write the number down where you cannot edit it.

Distinguish a channel failure from a demand failure. If nobody saw the page, you learned nothing about demand; re-run with real qualified traffic before concluding anything.

A negative result is a successful test. It cost you a week and saved you a quarter. Change the segment, the problem or the price and run it again — those are three separate variables and you should only move one at a time.