If you have spent any time researching software development, you have almost certainly encountered the term "MVP." Minimum Viable Product. Build small. Test fast. Iterate.
It is genuinely good advice — for the right kind of project. But not every software project is the same, and applying the MVP model indiscriminately leads to frustration on both sides: money spent on testing when you already knew what you needed, or a rushed build that does not answer the real questions.
This guide is for business owners trying to figure out which category their project falls into.
The three types of software projects
Most business software falls into one of three categories, and each has a different relationship with the idea of testing before committing.
Type 1: Process automation — You have an existing process that works. People are doing it manually, in spreadsheets, or in a system that no longer fits your needs. You know what the process looks like. You know who uses it and what it needs to do. The main unknown is execution: can this be built well, on time, and at a reasonable cost?
Type 2: New customer-facing product — You have an idea for something customers will interact with directly: a booking system, a client portal, an app that solves a specific problem for a specific audience. The main unknown here is demand: will the people you are building this for actually use it, pay for it, and change their behaviour around it?
Type 3: Internal tool with uncertain adoption — You want to digitise something internal — a workflow, a process, a reporting system — but you are not sure how your team will respond, or whether the tool will actually be used once it exists. The main unknown is fit: will this solve the problem in a way people actually adopt?
The key question is: what is uncertain?
If you are solving an uncertain demand or uncertain adoption problem, an MVP helps. If you are solving a well-understood process problem, you probably do not need one.
When you do not need an MVP
Let us start here, because the default in many conversations is "always build an MVP," which is simply not right.
You probably do not need an MVP when:
The process is already defined and proven. If your team has been running a procurement workflow for ten years and you want to automate it, you already know what the system needs to do. An MVP is not going to teach you anything new about your procurement process — you already know it. What you need is solid requirements, a good development partner, and careful project management.
You are replacing something that already exists. If you are migrating from one system to another, or rebuilding something that has been running for years in a different form, the user behaviour is already established. The risk is not "will anyone use this?" — it is "will the migration go smoothly?"
Your users have no choice. If your team is going to use this system regardless — because it is core infrastructure, or because management requires it — adoption is not the variable you need to test.
In these cases, spending extra time and money on a "minimum viable" version often slows you down without generating any useful learning.
When an MVP is genuinely valuable
When you are building for an audience whose behaviour you are predicting. The most common scenario: you believe customers will use a product in a certain way, and you have designed features around that belief. An MVP tests whether the belief is correct before you have built everything. Every assumption about how users will behave is a bet; an MVP is how you reduce the stakes on that bet.
When the cost of being wrong is high. If you are considering a €100,000+ investment in a product, the cost of testing a core assumption for €15,000 first is clearly justified. If the project is a €10,000 internal tool with a narrow scope, the cost of an extended validation phase may not be.
When speed to learning matters more than speed to completion. Sometimes a product needs to be in front of users fast — not because you are cutting corners, but because the market is moving and you need feedback to stay relevant. In that case, a disciplined MVP approach lets you get real insight early without waiting for a full build.
When the "right" answer is genuinely unknown. You may know the problem clearly but not know the best way to solve it. An MVP lets you test a hypothesis and adjust based on real usage, rather than spending months building one approach and finding out it was not the most effective path.
A practical decision framework
Before deciding whether your project needs an MVP, answer these four questions honestly:
1. Do I have a clear, testable assumption that the success of this project depends on?
If yes, an MVP can test it. If your main uncertainties are about execution — timeline, technical approach, integration complexity — an MVP is not the right tool. Those are what planning, scoping, and a good development partner are for.
2. Can I get meaningful feedback from real users with a partial build?
Some projects are only useful when they are complete — an accounting integration, for example, either balances or it does not. For those, partial testing does not tell you much. Others are genuinely testable at a reduced scope.
3. What is the cost of building the wrong thing fully?
If the total project cost is modest and the requirements are clear, the cost of an MVP phase may not be justified. If the total cost is significant and the requirements involve meaningful assumptions about user behaviour, testing first is worth it.
4. Do I have the discipline to stop after the MVP if the results are negative?
This one matters more than people acknowledge. An MVP only saves money if you are willing to act on what you learn — including stopping or changing direction. If organisational pressure means you will build the full version regardless of the MVP results, you have not really gained anything from the validation phase.
What to tell your development partner
If you have concluded that your project would benefit from an MVP approach, here is how to frame the conversation with your development partner:
- Be clear about what assumption you are testing, not just what you want to build.
- Ask them to help you define the minimum scope needed to answer that question meaningfully.
- Agree in advance on what "success" looks like — specific, measurable outcomes rather than general impressions.
- Set a clear timeline for review: when will you look at the results and decide what to do next?
A good development partner will push back on scope that does not contribute to answering your core question. If they agree to everything you ask for without challenging it, that is a warning sign — it usually means they are more interested in the build than in helping you make a good decision.
The real point
The term "minimum viable product" has become so common that it gets applied to almost everything — leading to both over-engineering (a "minimal" version that is 70% of the full product) and under-engineering (a rushed prototype not polished enough for users to engage with honestly).
The underlying idea is simpler and more valuable: do not spend more than you need to before you learn what you need to know.
Sometimes that means a disciplined MVP process. Sometimes it means starting with a focused, well-scoped project and learning from the first live version. Sometimes it means a short discovery and analysis phase before any development begins.
The right approach depends on your specific situation. The question to ask is not "should I build an MVP?" but "what is the minimum I need to invest to answer the most important open question about this project?"
Wondering whether your project needs an MVP or is ready to go straight into full development? Get in touch — we will help you figure out the right approach before you commit to anything.