"Just build an MVP."
It's become the default advice for anyone building software. Launch fast, learn from users, iterate. The lean startup playbook. And it's good advice — sometimes. Other times, it's the fastest way to waste money and credibility.
The MVP approach works in specific conditions. Outside those conditions, it backfires. Here's how we think about the decision, based on the projects we've delivered for clients who got it right and clients who learned the hard way.
What an MVP actually is
An MVP — Minimum Viable Product — is the smallest version of your software that delivers enough value for real users to adopt it. It's not a prototype. It's not a demo. It's not a broken version of the full product. It's a complete product with a narrow scope.
The "minimum" refers to features, not quality. An MVP should be well-designed, well-built, and reliable. It just does fewer things. If your MVP feels unfinished or buggy, it's not an MVP — it's a rushed product.
When launching small works
You're testing a market hypothesis. You think there's demand for a product, but you're not sure. An MVP lets you validate the idea with real users before committing the full budget. If nobody uses it, you've learned that for a fraction of the cost of building everything.
Your budget is limited and phased. You have enough to build the core but not the full vision. An MVP gets something into production that starts delivering value while you secure funding or generate revenue for the next phase.
The user feedback will change the product. You expect that what users actually need will differ from what you think they need. An MVP gives you real data to shape the next iteration instead of guessing.
Speed to market matters. A competitor is moving, a regulatory window is closing, or a seasonal opportunity exists. Getting something live in 3 months beats getting everything live in 9 months — if "something" is enough to capture the opportunity.
When launching small backfires
Your users are enterprise clients. If you're selling to corporations, procurement teams, or government agencies, they won't pilot a half-finished product. They expect a complete solution that checks every box in their requirements document. An MVP that's missing features they consider essential will get rejected — and you won't get a second chance.
The value requires a complete workflow. Some products only deliver value when the entire workflow is covered. A project management tool without task assignments isn't "minimal" — it's broken. If cutting features breaks the core use case, you can't MVP your way around it.
Trust is the primary barrier. If your product handles money, health data, legal documents, or anything where users need to trust the system completely, a visibly incomplete product destroys trust before you can build it. First impressions in high-trust categories are hard to reverse.
You already know what to build. If you've done extensive customer research, have validated wireframes, and understand the market deeply, an MVP adds a delay you don't need. You're not testing a hypothesis — you're executing a plan. Build the plan.
The middle ground: phased delivery
Most of our projects don't fall neatly into "MVP" or "full product." They fall into phased delivery — which takes the best of both approaches.
Phase 1 is a complete, polished product with a defined scope. It covers the core workflow end-to-end, and it's good enough to launch. But it deliberately defers the "nice to have" features to Phase 2.
This isn't an MVP in the startup sense — it's a strategic scope decision. The client gets working software in production faster, users get a complete (if focused) experience, and the Phase 2 roadmap is informed by real usage data instead of assumptions.
We've written about how our delivery process works — phased delivery is built into it. Every project starts with a scope document that explicitly separates Phase 1 from Phase 2, so the client knows what they're getting now and what's coming next.
How to decide what goes in Phase 1
The hardest part of any phased approach is deciding what makes the cut. Here's the framework we use with clients:
Start with the core workflow. What is the single most important thing the user needs to do? Build that end-to-end, with no gaps. If it's an invoicing tool, the user should be able to create, send, and track an invoice from start to finish in Phase 1.
Cut features, not quality. Phase 1 should have fewer features, not worse features. Every feature that ships should be well-designed, tested, and reliable. A polished product with 5 features beats a rough product with 15.
Defer what can be done manually. If a feature can be handled with a spreadsheet export, a manual email, or a workaround for the first 3 months, defer it. Automate it in Phase 2 when you know the volume justifies the investment.
Include what blocks adoption. If a missing feature will prevent users from using the product at all — authentication, data import, a specific integration — it must be in Phase 1 regardless of complexity. Adoption blockers aren't optional.
The cost difference
An MVP or Phase 1 typically costs 40-60% of the full product. Not 10%, not 20% — the core workflow still requires proper architecture, design, testing, and deployment. You're saving on feature breadth, not on engineering quality.
If someone quotes you an MVP at 10% of the full product cost, they're either cutting corners on quality or they haven't understood the scope. Either way, you'll pay the difference later — in bugs, rework, or a rewrite.
We've covered how long projects take and how pricing models work. The MVP decision directly affects both timeline and budget, so make it deliberately — not by default.
What this means for you
"Just build an MVP" is not always good advice. Neither is "build everything before you launch." The right answer depends on your market, your users, your budget, and your confidence in the requirements.
If you're unsure, start by answering this: can your users get meaningful value from a reduced feature set? If yes, launch small. If no — if the value requires completeness — build big, but build in phases.
We've put together a full set of resources for planning a software project: how to write a brief, when to build vs. buy, what to ask your agency, and what happens after launch. The MVP decision is one piece — but it shapes everything that comes after.
Planning a product and not sure where to draw the Phase 1 line? Let's figure it out together →