.avif)
.svg)
.svg){kind=small}
Table of Contents
Published on
1/9/26
-
5 min
Have a product idea but don't know where to start? Discover our support in product management, designed to turn an intuition into a quantifiable scope.
Everyone knows the MVP principle. Almost no one applies it correctly. In reality, the vast majority of projects that come to us labeled as an "MVP" already include fifteen features, three user profiles, and a full back-office. That’s no longer an MVP; it’s a v1 product with an MVP budget. And that is exactly how you lose money.
An MVP, or Minimum Viable Product, is the smallest thing you can build to learn something decisive about your market. The important word is neither "minimum" nor "product": it's "viable." Your MVP must solve a real problem for a real user, from the beginning to the end of the journey. A half-baked feature is not an MVP; it’s a failed prototype.
The nuance comes from the Lean Startup methodology formalized by Eric Ries, which relies on a simple loop: build, measure, learn. The MVP is just the first building block of this loop. Its value is not measured by what it contains, but by what it teaches you.
1. An MVP is not a mockup. A mockup generates no real behavior, only statements of intent.
2. An MVP is not a beta version. A beta assumes the product is already defined and you are looking for bugs. An MVP assumes the opposite: the product is not defined, and you are trying to find out if it should exist at all.
3. An MVP is not a free product. If your hypothesis is that people will pay, then the MVP must charge them. Otherwise, you are testing attractiveness, not the business model.
According to post-mortem analyses conducted by CB Insights, the number one reason startups fail is not funding, competition, or the team: it is the lack of a real market need, cited by about four out of ten failed startups. Cash flow issues come next, and they are often just a consequence of the former.
In other words: most products that fail don't die because they were poorly built. They die because they shouldn't have been built in the first place. This is information the market could have given you earlier, for a fraction of the cost.
Starting small is not a cost-saving strategy; it is a risk-management strategy. You aren't trying to spend less; you are trying to spend later, once the primary uncertainty has been removed.
Look at the logic in reverse. If your full product represents a budget of 80,000 euros and there is a 40% chance the market won't want it, your expected loss is 32,000 euros. A 20,000-euro MVP that answers that question cuts your exposure by more than half, regardless of the answer you get. A "no" is therefore very valuable, in the best sense of the word.
Most project founders arrive with a solution in mind and then look for the problem it solves. It’s comfortable, and it’s the source of almost every scope-related mistake.
Three questions are enough to set things straight:
- What specific problem, and for whom?
- How often does this problem occur?
- How do your users solve it today, in the absence of your product?
The third one is what matters most. If the answer is "they do nothing," the problem is likely not painful enough. If the answer is "they get by with a spreadsheet and a lot of patience," you’re onto something.
Imagine an app designed for freelancers to track their projects. Framed as a solution, the project becomes a project management tool—a saturated market where you have no competitive edge. Framed as a problem, it becomes: "a freelancer managing six clients at once doesn't know, at any given moment, how much they have billed and how much work remains to be delivered." This is much more focused, much more verifiable, and it immediately points to the two or three features that actually matter.
This step concludes with persona development. We detail the method in our guide on buyer personas, but keep the core principle in mind: a useful persona describes a context and a frustration, not an age range and a job title.
The MoSCoW prioritization, derived from the DSDM framework, classifies every feature into four categories: Must have, Should have, Could have, and Won't have this time. Its value lies in that last term. Most prioritization methods allow you to say "later." MoSCoW forces you to say "not this time," which is a much firmer commitment.
A point almost everyone overlooks: the DSDM framework recommends that Must have features should not exceed 60% of the total project effort, and that a buffer of about 20% should be kept as Could have. Beyond this threshold, project predictability collapses.
Apply this ratio to your MVP and the exercise becomes brutally clear: if everything is essential, nothing is, and your scope hasn't been properly defined.
A second, even simpler filter. List the minimal path a user must be able to complete from start to finish for the product to make sense. Anything not on this path is out of scope, no questions asked. A user account, a settings page, and a dashboard are almost never on this path.
This discipline then feeds your product roadmap : what you set aside today isn't lost, it's just scheduled for later.
The sequence is always the same. A wireframe establishes the structure without worrying about style. A prototype makes the user journey testable. Figma covers both stages and remains the go-to tool for sharing designs with non-technical stakeholders.
A misunderstanding caught during the design phase takes an hour to fix. The same issue caught after development takes days, or can even require a complete data model overhaul. It is the best return on investment in terms of effort versus risk mitigation for the entire project.
This is also the moment whereUX design takes precedence overUI design. For an MVP, the quality of the user journey far outweighs visual sophistication. Our design team UX/UI always work in this order.
Platforms no-code allow you to get a functional product online in just a few weeks. Webflow for a public-facing interface and a landing page that converts, Bubble for an application with business logic and user accounts, Airtable as a database that can be managed by a non-technical team.
There is a real trade-off that must be acknowledged: you gain speed, but you lose control over costs at scale and architectural freedom. Our comparison of no-code and low-code tools details the thresholds at which switching becomes necessary.
If your differentiation relies on an algorithm, heavy data processing, complex integration, or compliance requirements, no-code becomes a ceiling from day one. This is typically the case for SaaS software aimed at professionals. We have broken down the expenses in our article on custom SaaSdevelopment.
In practice, the winning combination often consists of handling the visible part with no-code while custom-developing only the component that drives your value. You focus your technical budget where it truly differentiates you.
A classic mistake is to launch and then look at the numbers to see what they say. Do the opposite. Before going live, write down in black and white the threshold that will validate or invalidate your hypothesis. For example: 30% of registrants complete the main journey within seven days. Without this pre-defined threshold, any data can be interpreted in whatever way suits you.
Usage metrics tell you what people do. They never tell you why. A behavioral analysis tool like Hotjar (https://www.hotjar.com/) shows where users drop off, but only interviews will tell you what they were looking for at that moment.
Ten twenty-minute interviews with real users provide more value than a survey with two hundred responses. The former reveal reasons, while the latter mostly confirms your own questions.
This is the question the Lean Startup loop poses at every cycle. Three outcomes are possible: the market confirms and you invest, the market rejects and you save the rest of the budget, or the market reveals a related need and you pivot. All three responses are MVP successes. The only failure is learning nothing.
Once the hypothesis is validated, the real question becomes budgetary. We have addressed this in our guide on the budget required to scale an MVP after its launch.
1. Expanding the scope along the way. Every addition pushes back the moment you learn something, which is exactly what the MVP was meant to avoid.
2. Launching without a written hypothesis. If you don't know what you're testing, no result can prove you wrong.
3. Confusing enthusiasm with validation. Compliments from friends and family are not data. A user who returns without being prompted is.
4. Focusing on the product rather than the user journey. An MVP can be visually modest. It cannot be incomprehensible.
5. Waiting until you're ready. The product is never ready. The only reliable benchmark is the complete minimal journey defined in step 2.
Starting small isn't about saving money; it's a method for buying information at the best price. A well-scoped MVP costs a fraction of a full product and tells you whether it should be built. A poorly scoped MVP costs almost as much as a full product and tells you nothing.
The difference between the two lies entirely in step 2, in your ability to write down in black and white what you will not do. This is the uncomfortable part of the work, and it is where an outside perspective is most valuable.
Want to know what your MVP looks like in terms of scope, budget, and timeline? Describe your project to us, and we will get back to you within 48 hours with a detailed estimate: request a quote.
