MVP or full product? How to decide where to start

You have a product idea and a question that comes back at every meeting: do we start small and validate, or build something complete right away? It's one of the most expensive decisions a founder makes, because it shapes budget, timeline and the risk of discovering too late that the market wanted something else. There's no dogmatic answer: it depends on what you're trying to learn.

What an MVP actually is (and what it isn't)

An MVP, Minimum Viable Product, isn't a poorly built product, nor a demo with half-finished features. It's the minimum needed to validate a hypothesis: that a real problem exists, that people are willing to use (or pay for) your solution, that the value you imagine matches the value they perceive.

The key word is "viable": it has to genuinely work for the people using it, on the slice of the journey it covers. A lean but solid MVP always beats a broad but shaky product. The goal isn't to impress, it's to learn fast with minimal investment.

Choosing the essential features (and cutting the rest)

The heart of an MVP is the discipline of cutting. For every feature, one question: does it help validate the hypothesis, or is it just "nice to have"? If it doesn't help answer the central question, it's out of the first release.

A method that works:

• Identify the single critical flow: the path that takes a user from problem to value. That one has to be flawless.
• Push everything else to "later": advanced accounts, integrations, customizations, edge cases. Almost nothing is truly essential at launch.
• Substitute where you can: a manual process behind the scenes is often worth as much as automation, at a fraction of the cost. Validate first, automate later.

Cutting is scary, but every feature you remove is time gained toward real feedback.

The two mistakes we see most often

Almost every MVP that fails falls into one of two opposite extremes:

• The bloated MVP. Under the pressure of "let's do it right from the start," the first release piles up features, screens and options. The result: months of development, budget burned, and you reach the market without having learned anything yet. It's a full product disguised as an MVP.
• The too-bare MVP. The opposite extreme: you cut so much that the product no longer says anything. If users can't actually experience the core value, their indifference doesn't mean the idea is wrong, it just means they never saw it work.

The sweet spot is in the middle: complete enough to produce an honest judgment, lean enough to build it fast.

When an MVP isn't the right call

We'll say it against the grain: an MVP isn't always the way to start. There are contexts where a "minimal" product does more harm than good, because here trust is the product:

• Regulated sectors: fintech, healthcare, anywhere a mistake has legal or safety consequences. You can't ship a version that's "good enough" compliant.
• Products where the first impression is final: if your audience is demanding and the market is crowded, a half-baked version burns your reputation before it gives you a second chance.
• When the hypothesis is already validated: if you know for certain the demand exists, the MVP becomes a redundant step: better to invest in a solid product from the start.

In these cases, the minimum isn't "few features", it's non-negotiable quality across a narrow scope.

Why a well-built MVP really saves you money

When it makes sense, a well-built MVP is the cheapest choice you can make, not because it costs little, but because it gets you to the feedback that matters sooner. Instead of spending six months on an idea only to discover the market wanted something else, you learn in a few weeks what works and what doesn't, with real data rather than opinions.

Every decision after that becomes better informed: what to build next, what to cut, where to invest. It's the difference between building in the dark and building with the lights on.

In short

MVP or full product isn't an ideological choice: it's a question of what you need to learn and how much risk you can afford. Start small when you need to validate a hypothesis; build more when trust is on the line or the demand is already confirmed.

If you're deciding where to start with your project, we can think it through together: often a free brief is enough to find the shortest path to your goal.