"Just build an MVP" is advice I've given and received dozens of times. It sounds obviously correct. Ship something small, validate quickly, iterate. Simple.
Except almost nobody actually does it. What they build is a V1 — a fairly complete version of what they imagined — and then call it an MVP to feel lean.
I've fallen into this trap. My clients fall into this trap. Smart engineers with real product experience fall into this trap. Here's why it happens and how to actually escape it.
Why the MVP Trap Exists
Building software feels like making progress. Every feature you add is a visible, tangible thing that exists and works. Cutting features feels like giving up, like lowering ambitions.
There's also a fear layer. The fear that the stripped-down version will look amateurish. That users won't "get it" without the supporting features. That competitors will have more features. That you'll be embarrassed.
These fears are almost always wrong, but they're powerful.
The third reason is more insidious: engineers love solving problems. The second you define a feature, an engineer's brain starts architecting the solution. That architecture then justifies the feature, because now work has been done. The feature's importance gets inflated retroactively by the investment already made.
What an MVP Actually Means
An MVP is the smallest thing you can build that allows you to learn whether your core hypothesis is true or false.
Note what that definition doesn't include: users loving it, it being polished, it handling edge cases, it being scalable.
A hypothesis looks like: "Restaurants will pay $49/month for a digital staff scheduling tool instead of using WhatsApp groups."
The MVP to test that hypothesis is... honestly not much. It might be a Google Form and a Notion database manually managed by you. It might be a Typeform that sends an email when someone submits a shift. Before you write a single line of code, there are ways to test whether the core assumption is true.
When I started QuickShift, I almost jumped straight into building the full Flutter app. Shift posting, claiming, push notifications, manager dashboard — I had it all planned. Then I stopped and asked: What am I actually trying to learn first?
The first hypothesis was: Do hospitality managers find the shift-claiming approach appealing enough to share it with their staff?
I tested that with a two-page landing page and a Calendly link. Three managers booked calls. That told me it was worth building. I still built less than I planned for the beta, but dramatically less than the original scope.
The Hardest Cut
The hardest features to cut are the ones that feel necessary for the core experience. The "this won't make sense without X" features.
My framework for evaluating these:
Ask: Is this blocking me from learning? If the hypothesis can still be tested without this feature, cut it. You're not building for completeness; you're building to learn.
Ask: Who actually asked for this? If no one has explicitly asked for this feature, you're building on assumptions. Assumptions are expensive. Cut it until someone asks.
Ask: What's the worst case if I ship without it? Usually the answer is "users will ask for it" or "some users will churn." Both of those are information. Both are better than spending two weeks building something nobody wanted.
The Permission to Disappoint
The hardest mental shift is accepting that your MVP will disappoint some users. It might feel unfinished. Some will churn. Some will tell you what's missing.
That's the entire point.
Disappointment is information. If ten users tell you the same thing is missing, you know what to build next. If nobody says anything, you either nailed it or nobody's actually using it — both are things you need to know.
A polished V1 that nobody wants to use is far worse than a rough MVP that generates clear signal.
What I Tell My Clients Now
Before we scope any project, I ask: What's the single thing we need to learn to decide whether to keep building?
Then we build exactly enough to learn that thing.
It's almost always less than they think. And it almost always ships faster, surprises them with early users, and generates better feedback than a fully polished V1 would have.
Build less. Learn more. Then build the right things.