MVP or Finished Product Right Away?
An MVP is the smallest version that tests whether anyone wants the product, before you build everything. The biggest cost in product development is building the wrong thing, and an MVP is the insurance against exactly that. Build the finished product right away only when reality demands it – regulated industries, public procurement, or paying enterprise customers from day one.
The question comes up at the start of every product initiative: build a stripped-down first version, an MVP, or go straight for a finished product with everything in place? The answer determines both budget and risk. An MVP – minimum viable product – is the smallest version that can genuinely test whether anyone wants what you’re planning to build. A finished product is the entire vision, built before the market has had its say.
The biggest cost is building the wrong thing
In product development, the most expensive line item is rarely the development hours. It’s building something nobody wants. A finished product costing, say, two million kronor that meets a market shrugging its shoulders means the entire sum is lost – not because the work was bad, but because it was aimed wrong.
This is where the MVP is pure risk reduction, and it’s a calculation you can actually run. An MVP costing a fraction of the finished product can deliver the same answer about whether the market wants the solution – just much earlier and much cheaper. If the hypothesis fails, you’ve lost the small sum instead of the large one. If it holds up, you’ve also gained paying users and real insights to build on. The odds in that calculation are hard to beat.
The point isn’t to save money by building less. The point is not to commit the entire budget before you know you’re building the right thing.
When building the finished product right away is actually correct
MVP thinking is powerful but not universal. There are situations where a stripped-down first version can’t be launched meaningfully, and where you need to reach a floor of features from the start:
- Regulated industries. In healthcare, banking, and insurance, legal requirements have to be met before the first real user gets let in. You can’t scale away requirements for security, traceability, or regulatory compliance and call the rest an MVP.
- Public procurement. A procurement specifies what has to be delivered. There, the requirements list determines the scope, not your hypothesis about the market.
- Paying enterprise customers from day one. If you already have a big customer with a contract and a list of required features, the expectation is a working product, not an experiment. The market risk has effectively already been answered.
What these have in common is that the market risk – does anyone want this? – is already resolved or replaced by a binding requirement. Then the MVP’s main point loses its meaning, and it becomes reasonable to build broader right away.
A worked example
Say the finished product costs 2 million kronor and takes a year. Path A: build everything right away. After a year, it turns out the feature people actually wanted was something quite different from what you thought. Most of the work was wasted, and you’re still facing a rebuild.
Path B: build an MVP around the core hypothesis for SEK 400,000 over three months. Users clearly show what they actually want – partly something different from what was planned. You adjust course and build further on what’s been validated. The final total might end up the same, but the money lands on the right product. The difference between the paths isn’t the cost – it’s the likelihood that the money produced something worth having.
How to design an MVP to grow, not get thrown away
A common objection is that an MVP is wasted since it has to be rebuilt anyway. That’s only true if it’s built as a one-off experiment. An MVP can just as easily be built as the first step of the real product:
- Stick to a stack that carries forward. Choose technology and architecture that can handle the product at full scale, and the MVP can be developed further instead of rewritten.
- Cut breadth, not quality. Build fewer features properly rather than many features sloppily. What gets built should hold up; what’s missing gets added later.
- Leave doors open. Design the core so the deprioritized features can be hung on later without tearing down the foundation.
Done this way, the MVP isn’t a cost alongside the product – it is the product’s first version. At Weapp we normally build MVPs exactly this way as part of our services, with a deliberate choice about whether it should carry forward or be a pure experiment.
Not sure how much you need to build to get an answer to your most important question? Get in touch and we’ll help you scope it.
Frequently asked questions
Is an MVP a half-finished product?
No, that's a common misconception. An MVP is fully finished for its purpose – testing the most important hypothesis with real users. The difference from a finished product is breadth, not quality: it does one thing properly instead of ten things half well. A sloppy MVP only tests whether people put up with bugs.
Doesn't an MVP risk looking unprofessional?
Only if it's done sloppily. A well-scoped MVP can feel thoroughly built within its small area. Most early users forgive missing features, but not features that are broken. Focus the quality on the core, and the product comes across as serious despite being small.
How do we know if we're one of the exceptions that need to build more right away?
Ask the question: can we even launch a stripped-down version legally and credibly? In a regulated industry, a public procurement, or with an enterprise customer with a requirements list, the answer is often no – then there's a floor of features you have to reach before the first user. There, a pure MVP is the wrong path.
Can an MVP be built on, or does it have to be rebuilt?
It depends on how it's built. An MVP on a stack and architecture that carries forward can grow into the finished product step by step. An MVP in throwaway technology, meant to prove something fast, often has to be rewritten afterward. Decide from the start which of the two it should be.
What does it cost to skip the MVP step?
The risk is that the entire investment goes into a product nobody wants. Build the finished thing right away for millions of kronor and the market doesn't respond, and the whole sum is lost. An MVP for a fraction of that would have delivered the same answer sooner. The cost of skipping the step is therefore the size of the mistake you didn't catch in time.