Why Do You Need an MVP?

Almost every founder who comes to Cambalache Studio with a new idea wants the same thing: the full product, every feature they've been imagining for months, ready to launch. It's a logical reaction — if you already know exactly what you want to build, why build "less"? The problem is that logic rests on an assumption that almost never holds: that what the founder imagined at their desk is exactly what the market needs.

That's the core mistake we see over and over, and this piece is for the founder who isn't yet convinced they need to shrink the scope before building anything.

The core mistake: building everything you imagined, without testing any of it first

When an idea has been spinning around in your head for months (or years), it becomes very concrete in there: the feature list grows, the user flow gets polished in your imagination, and at some point it starts to feel like "it's all figured out, all that's left is to build it."

That's exactly the moment of highest risk. Because everything you figured out, you figured out without a real user in front of you. No amount of research inside a founder's head replaces what happens when an actual person, with real money and real time on the line, uses the product for the first time. Surprises show up almost every time: features nobody touches, a flow that confuses people where it seemed obvious in your head, a problem that didn't hurt nearly as much as you assumed.

Building the full product before you have that evidence means betting months of development on the idea that the founder got everything right from behind a desk. Sometimes that happens. Most of the time it doesn't — and that's where the money goes.

What an MVP is, without the jargon

An MVP (minimum viable product) is the smallest version of your product that already solves the core problem for a real user — solves it well enough that they'll actually use it, or pay for it. It's not a half-finished version or a pretty demo: it's a deliberate cut that does one thing well, so you can learn whether your idea actually works before investing in building everything else.

The question an MVP answers isn't "do I like how it turned out?" It's "does someone, with real money or real time on the line, choose to use this instead of whatever they were doing before?"

The real risk of skipping it

The risk isn't abstract, it's very concrete: spending six to twelve months building a product with every feature you imagined, spending the founder's money or investors' money, only to find out at launch that nobody wants it as-is.

At that point there's no room left to pivot calmly. The team was staffed for a big product, fixed costs ran the whole time, and a fix that would have cost a week of work on an MVP now means rebuilding months of code and architecture decisions. It's the most expensive way to fail in product development — not because of bad execution, but because you validated too late, after the money and the time were already spent.

When it actually makes sense to skip the MVP (or shrink it even further)

This isn't a dogma. There are real situations where building big from day one is the right call:

• You've already validated demand somewhere else. You have a long waitlist, real pre-sales, or an analogous business (offline, manual, in another market) that already proved people pay for this.
• It's a new feature on a product that already has users. If you already have an active user base and you're adding a feature, you're not validating an idea from zero — you're iterating on something that already works, and you can lean on those users to measure impact quickly.
• It's not a new idea, it's a copy with better execution. If the market has already proven the model works (there are competitors with real traction) and your bet is executing it better, the open question isn't "does demand exist?" but "can I execute better?" — an MVP still makes sense here, but it can be a lot smaller and faster.

Outside those cases, skipping the MVP means betting that you got it right without any evidence yet.

Do you need an MVP? Four questions to ask

If you answered no to most of these, that's not a red flag — it's the most common situation there is. It just means the next step is an MVP, not the full product.

What you learn from a well-built MVP, beyond "did it work"

The binary question — "did it work or not" — is the least interesting thing an MVP answers. What actually justifies the money spent is the specific stuff:

• Which features people actually use. There's almost always one or two features that concentrate real usage, and several the founder considered "essential" that almost nobody touches.
• What confuses a real user. A flow that made perfect sense in your head (or in Figma) creates friction at one specific step nobody anticipated.
• What people are actually willing to pay for, and why. It's not enough to know someone pays — what matters is whether they pay for the core feature you imagined, or for something secondary that turned out to be the real perceived value.

That information reshapes the full product's roadmap with real data, instead of the same assumptions you started the project with.

Conclusion

Wanting the full product from day one is a natural reaction when the idea is already crystal clear in your head — the problem is that "clear to you" isn't the same as "validated with real users." An MVP isn't a lesser version of the product you dreamed up: it's the step that tells you, with real evidence and before you spend months of development, whether that dream matches what the market actually needs. If you're still not sure your idea has real demand, the step before the MVP is validating the idea; and if you already have that validation but the terms "MVP," "prototype," and "full product" still blur together, it's worth checking how the three differ before you define the scope.