Why most MVPs fail before launching
The most common mistake is building too much. A team spends 6 months developing 10 features when they only needed 1 to validate the core hypothesis. The result: the product reaches the market late, with budget exhausted and no energy to iterate when first users give feedback.
The second mistake is confusing 'minimal' with 'broken'. An MVP has to work. What can be minimal is the scope, not the quality. A product that fails or confuses users doesn't validate anything: it invalidates the experiment.
Defining the MVP in 3 questions
Before writing a line of code, we answer these 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 specific situation is willing to pay X€ to solve this specific problem'.
- What is the minimum functionality that allows falsifying that hypothesis? If the hypothesis is that users will pay, the MVP needs a payment flow. Not a demo without monetization.
- Who are the first 5-10 users? Not the abstract 'market', but specific people who already have the problem, know it, and have a budget to solve it. If you can't name them, the hypothesis isn't defined enough.
The stack we use to launch in 6-10 weeks
The speed of an MVP depends on the stack as much as the team. The stack we repeat because it works: Next.js for frontend and API routes, Supabase for database and authentication, Stripe for payments, even if monetization is future, integrating it from the start avoids rework, and Vercel or Railway for deployment.
We avoid microservices, distributed architectures and any complexity that isn't necessary for the core hypothesis. The rule: if the technical complexity doesn't serve the hypothesis, it doesn't go in the MVP.
MVP success metrics (must be defined before launching)
Defining metrics before launch avoids confirmation bias. Metrics depend on the hypothesis: if the hypothesis is desire, 'do users want this?', we measure registration rate and time to first key action. If it's willingness to pay, we measure trial-to-paid conversion. If it's retention, we measure DAU/WAU at 2 and 4 weeks.
An MVP without pre-defined metrics is just a product. An MVP with metrics is an experiment that can learn.
Frequently asked questions
A well-defined MVP with the right stack costs between €15,000 and €40,000, including UI/UX design, development, QA and deployment. MVPs that exceed this figure have usually failed in the definition phase: they have too many features to be minimal. Those that cost less than €8,000 usually lack the quality necessary to generate valid learning.
Between 6 and 12 weeks for most B2B or B2C digital products. If the MVP takes more than 3 months, it's probably not truly minimal. The market changes, competitors move and the founding team loses energy. Speed is part of the validity of the experiment.
An MVP that fails correctly is a process success. If the hypothesis is falsified with real user data, you've learned more in 8 weeks than you would in 2 years of development. The failure to avoid is the one that generates no learning: the product nobody uses and you never know why.