Why most MVPs fail before launching
The most common mistake is building too much. A team spends six months developing ten features when one would have validated the core hypothesis. The result: the product reaches the market late, the budget is gone and there is no energy left to iterate when the first users give feedback.
The second mistake is confusing 'minimal' with 'half-built'. An MVP has to work. What can be minimal is the scope, never the quality. A product that breaks or confuses people validates nothing: it invalidates the experiment.
Defining the MVP in 3 questions
Before writing a line of code, we answer three questions with the client:
- What is the single hypothesis we want to validate? Not 'whether the market wants this' (too broad) but 'whether a user in this particular situation will pay €X to solve this particular problem'.
- What is the least functionality needed to prove that hypothesis wrong? If the hypothesis is that users will pay, the MVP needs a working payment flow, not a demo with monetization left out.
- Who are the first five to ten users? Not the abstract 'market' but named people who already have the problem, know they have it, and have budget to solve it. If you cannot name them, the hypothesis is not tight enough yet.
The stack we use to launch in 6-10 weeks
How fast an MVP ships depends on the stack as much as on the team. The one we come back to because it works: Next.js for the frontend and the API routes, Supabase for the database and authentication, Stripe for payments (worth wiring in from the start even when monetization is still some way off, because it saves rework later) and Vercel or Railway for deployment.
We stay away from microservices, distributed architectures and any complexity the core hypothesis does not need. The rule: if the technical complexity does not serve the hypothesis, it does not go into the MVP.
MVP success metrics (must be defined before launching)
Setting the metrics before launch is what keeps confirmation bias out. Which ones you use depends on the hypothesis. If the hypothesis is desire ('do users want this?'), measure the sign-up rate and the time it takes to reach the first key action. If it is willingness to pay, measure trial-to-paid conversion. If it is retention, measure DAU/WAU at two and four weeks.
An MVP with no metrics agreed in advance is just a product. An MVP with metrics is an experiment you can learn from.
Frequently asked questions
A well-defined MVP built on the right stack costs between €15,000 and €40,000, including UI/UX design, development, QA and deployment. The ones that go over that figure have usually gone wrong at the definition stage: too many features to count as minimal. The ones that come in under €8,000 rarely have the quality needed to produce a valid answer.
Between 6 and 12 weeks for most B2B or B2C digital products. If it takes more than three months, it is probably not minimal at all. The market shifts, competitors move and the founding team runs out of steam. Speed is part of what makes the experiment valid.
An MVP that fails properly is still a win. If real user data disproves the hypothesis, you have learned more in eight weeks than you would in two years of development. The failure to avoid is the one that teaches you nothing: the product nobody uses, and you never find out why.