Loading page…
An AI assistant is planned. Until it is genuinely useful we would rather point you at the page that actually answers your question.
A minimum viable product is the smallest thing you can put in front of real users that produces a real answer to a real question. The question is usually whether people will use it, whether they will pay, or whether the core mechanic works at all outside a pitch deck.
The word doing the work is "viable". An MVP is not an unfinished product — it is a complete, working product with a deliberately narrow scope. Users judge what is in front of them, not what is planned, so the part you ship has to be genuinely good.
Building the full vision before contact with users is how startups spend a year and a funding round finding out the premise was wrong. An MVP compresses that feedback loop from a year to a couple of months, while the cost of being wrong is still small.
It also changes fundraising conversations. A working product with even modest usage data is a materially different pitch from a deck describing intent. Investors respond to evidence, and an MVP is the cheapest way to produce some.
Our approach
We start by naming the riskiest assumption, then scope backwards from it. If the risk is whether people will pay, the MVP needs payments and can skip settings and admin. If the risk is whether the matching works, it needs the matching and can handle onboarding manually. Everything not testing the assumption is a candidate for removal.
We use boring, proven technology deliberately. An MVP is the wrong place for novel infrastructure — the goal is to learn something about the market, not about a new database. Established tools with good documentation mean fewer surprises and a faster path to a working release.
We are explicit about what is deliberately unfinished. Manual processes behind an automated-looking interface are often the right call at this stage. What matters is recording those decisions so the shortcuts are known debts rather than forgotten landmines.
Capabilities
Working out what genuinely has to exist for the test to be valid, and what can wait without invalidating it.
A complete, working slice of product — not a prototype, and not a demo that falls over on real input.
Signup, subscriptions or one-off payments where willingness to pay is the thing being tested.
Instrumentation for the specific behaviour you are testing, decided before launch rather than added after.
Deployment, domains, monitoring and the operational basics needed to put it in front of real users.
Short cycles responding to what usage actually shows, which is where an MVP earns its value.
Stack
Process
Naming what the MVP must prove, then cutting scope back to what tests it. Usually the hardest conversation.
The primary journey designed properly — first impressions still count, even in a narrow product.
Weekly releases you can open and use, so scope conversations happen against working software.
Tracking the specific behaviour that answers your question, not a generic analytics install.
Getting it in front of real users, with monitoring and a route for their feedback.
Reviewing what usage shows and deciding deliberately whether to continue, change direction or stop.
Use cases
Where the fundamental question is whether anyone wants this, and no amount of research will settle it.
Where a working product and early usage data materially change the conversation with investors.
Testing a new offering without committing the budget a full build would require.
Where the risk is whether something can be built at acceptable cost and performance at all.
Outcomes
FAQ
Related