How should a founder choose the lightest MVP that still tests the riskiest assumption?
Founders do not need the fullest build first. They need the smallest test that can answer the hardest question: do people want this, can they use it, or will they pay for it?
On this page
Start hereChooseHow it worksTrade-offsGuardrailsNext stepsIn short
- Start with the riskiest assumption, not the nicest idea.
- Pick the lightest test that can answer that one question.
- Use landing pages for demand, prototypes for usability, concierge pilots for process fit, and thin live builds for real-world behaviour.
- Avoid building more until the test produces evidence you can act on.
- If the risk is operational or technical, a live build may be the only honest test.
The cheapest valid test is usually the one that proves the main risk, not the one that looks most complete.
That matters because many early projects fail for the wrong reason. Teams spend too long building features before they have answered a basic question: is there real demand, will the workflow work in practice, or can we deliver the service reliably at all?
The right MVP is not the smallest thing you can build. It is the smallest thing that can still give you a decision you trust.
Begin with the question you most need to answer
An MVP is best understood as a learning tool. NN/g describes it as the simplest version of a product or feature that helps a team assess whether users will derive meaningful value from it. That means the first job is not to ship everything. It is to reduce uncertainty.
For founders and non-technical owners, the key question is usually one of four things: do people want this, will they understand it, can we deliver it by hand, or does the live system behave safely and consistently? The answer decides the test.
Match the test to the risk
Landing page
Best when the main risk is demand. You are checking whether people click, enquire, join a waitlist or request access. Shopify’s validation guidance supports using lightweight tests such as landing pages and other early signals before a fuller build.
Prototype
Best when the main risk is comprehension or usability. A prototype helps people react to the workflow, layout or service concept before you invest in production code. It is useful when you need feedback on structure, not operations.
Concierge pilot
Best when the main risk is whether the service works in practice. You deliver the outcome manually, or partly manually, to learn what customers actually need and where the process breaks.
Thin live build
Best when the main risk is technical or operational behaviour. If you need to know how the product works with real data, accounts, integrations or timing, a live build may be the only honest test.
What each option tells you, and what it does not
| Test | What it is good for | What it is not good for |
|---|---|---|
| Landing page | Demand and message clarity | Proving delivery, usability or retention |
| Prototype | Usability, understanding and flow | Reliability, performance or integration risk |
| Concierge pilot | Process fit, service quality and edge cases | Scalable automation or clean handover |
| Thin live build | Real-world behaviour and operational risk | Broad feature completeness or polished design |
Shopify’s guidance on validation and business-idea testing points in the same direction: define the concept, speak to customers, choose a test, then decide whether to proceed, rework or stop based on what you learn. The test should fit the decision, not the other way round.
Why lighter is not always better
- A landing page can overstate interest if the offer is vague or the traffic is unqualified.
- A prototype can hide delivery problems because it does not face real systems, users or data.
- A concierge pilot can create useful learning, but the manual effort can be hard to repeat and may distort cost assumptions.
- A thin live build can reveal the truth fastest, but it also introduces more implementation work and more places to make mistakes.
Avoid the most common validation mistakes
0 of 5 complete
A simple way to decide this week
- 1
Name the riskiest assumption
Write one sentence: ‘We do not know whether…’
- 2
Pick the lightest test that answers it
Demand points to a landing page, usability points to a prototype, process fit points to a concierge pilot, and operational truth points to a thin live build.
- 3
Define success before you run the test
Decide what evidence would let you continue, change course or stop.
- 4
Keep scope narrow
Remove anything that does not help answer the chosen question.
- 5
Review what you learned quickly
Use the result to decide the next step, not to justify a bigger build by default.
If you choose well, the MVP will feel slightly incomplete. That is normal. The goal is not completeness; it is confidence. The best first test is the one that lets you make the next decision with less guesswork and less waste.
About the author
Nixim Team, Product Engineering
Practical guidance from Nixim on building software, working with AI and running dependable cloud systems.