Every client comes with the full picture in their head.
Every feature. Every screen. Every detail. The complete product, ready to launch and take the market by storm.
And almost every time I say the same thing: let's not build that first.
The reaction is always the same
The reaction is predictable.
"We're not in a hurry. We want to go to market strong. We don't want to launch something incomplete."
I understand it. Nobody wants to show up with half a product.
The fear underneath is reputational. You get one first impression, and launching thin feels like spending it badly. That's a fair worry attached to the wrong conclusion — because the thing that actually damages a first impression isn't a small product. It's a product nobody asked for, delivered six months late, with a feature list built entirely out of guesses.
And that feature list is usually softer than it looks. It arrived as a vision and a deadline rather than actual requirements, which means half of it is preference and nobody in the room knows which half.
The apps you use every day
So I ask them to think about the apps they use every day.
WhatsApp started as a simple status update tool. No voice calls. No video. No stories. Uber launched in one city with one feature — request a car. The products they know and trust today were not what launched on day one.
They started small. They found out what the market actually wanted. Then they built more.
Here's the trap in comparing yourself to them. You're not looking at their version one. You're looking at a decade of corrections, and every one of those corrections was paid for by someone using the product and complaining about it.
The product in your head is not version one. It's version forty — and versions two through thirty-nine were written by customers, not by you.
What months of building actually cost
This is the part most people miss.
If you spend months building the full product and launch to discover the market isn't interested — you have a serious problem. Not just the money spent. The time. The opportunity cost. The assumptions that turned out to be wrong.
The money is honestly the smallest line on that list. Money you can raise again. The six months you spent not talking to a single real customer are gone, and so is whatever a competitor did with the same six months. Worse, you now own a large, finished, expensive product — and large finished products are much harder to change than small ones. Every wrong assumption is baked into code that other code depends on.
An MVP gets you to market in weeks instead of months. Real users. Real feedback. Real signal.
Does the market want this? Which feature do they actually use? What did we build that nobody touches?
You find out fast, while you still have budget to adjust.
What an MVP is not
The word "minimum" does a lot of damage here, so let me be precise about what I mean.
In my work, I always build the MVP first. A complete, functional product end to end — just focused. Then we grow it based on what the market tells us, not what we assumed in a meeting room.
An MVP is narrow, not shallow. That distinction is the whole thing:
- Not a prototype. A prototype is thrown away. An MVP is the foundation you keep building on, which means the architecture, the database and the security are done properly from day one.
- Not a demo. Real users, real data, real money moving. A demo tells you people like the idea. An MVP tells you whether they'll use it on a Tuesday afternoon when they're busy.
- Not half-built features. Every feature that ships is finished. You cut scope by removing whole features, never by shipping broken halves of them.
- Not permanent. It's version one of something that keeps growing, not a cheaper version of the real thing.
And a genuinely honest aside, since I'm the one billing for the hours: a longer project pays me more. I still push for the MVP. Building the wrong product slowly is a bad outcome for you and a worse reference for me.
I took my own advice on this one. Stokka went from the decision to build to a live, downloadable product in seven weeks. Not because there was nothing left to add — there's plenty, and users are telling me what it should be. Because seven weeks was long enough to find out whether anyone would pay for it.
The 80/20 rule
There's one more thing worth knowing.
The 80/20 rule holds in software more than almost anywhere else. 80% of your users will use 20% of your features. Consistently. Across almost every product ever built.
Which means the most important decision isn't what to build — it's what to build first.
Start with the 20% that matters. Ship it. Learn. Then decide what comes next.
The catch is that nobody can identify that 20% from a meeting room. You'll be confident about it, you'll be wrong about a third of it, and the only reliable way to find out is to put something in front of people. That's not a reason to skip the thinking. It's a reason to stop thinking sooner and go check.
Build fast. Learn faster. Then build the rest.
