"Just build an MVP" is the most repeated and least useful piece of startup advice in circulation. It's not wrong, it's incomplete. An MVP is the right move for some founders and a thinly-disguised disaster for others. This guide is the framework we use at DevEntia when a founder asks us "should I build the lean version or the polished v1?"
The version you build first is rarely the version that will scale. But it's almost always the version that determines whether you have a business at all.
What "MVP" actually means (and what it doesn't)
The original MVP definition from Eric Ries was deliberately strict: the smallest experiment you can ship to test a falsifiable hypothesis with real users. It is not "version 1 with bugs." It is not "we'll polish later." It is a learning instrument. Most "MVPs" we see in the wild are actually small full products with embarrassing UX, which gives founders the worst of both worlds.
An MVP that hides nothing is honest engineering. An MVP that pretends to be a real product is a marketing problem disguised as a build decision.
When MVP is the right call
| Signal | Why MVP wins |
|---|---|
| Unproven market, you've never sold this exact thing | Cheap to fail, fast to learn |
| B2C / consumer audience that tolerates rough edges | Acquisition is the bottleneck, not polish |
| You can charge from day one (paid waitlist, presale, founding members) | Real money beats real surveys for validation |
| Marketplace dynamics, you need both sides at once | Manual matching beats automated empty marketplace |
| You're solving your own painful problem | You're the first user; iterate against your own usage |
Classic well-publicized examples: Airbnb's first MVP was three air mattresses in a San Francisco apartment with a one-page site. Stripe's first MVP was seven lines of JavaScript that processed credit cards via a Founders' personal phone number support line. Both were "embarrassing" by polished-product standards. Both validated the core hypothesis at near-zero cost.
When MVP is a trap
The cases where the lean MVP advice misfires are the cases where the cost of looking unfinished is higher than the cost of building right:
- Regulated industries (fintech, healthcare, legal). Compliance and audit costs don't scale down with feature scope. You'll pay 80% of the cost of a full product to ship the first 20% of features.
- B2B mid-market and enterprise. Buyers expect SSO, audit logs, role-based permissions, and a real onboarding flow. An "MVP" in this market is a lost demo.
- Network-effect products competing against incumbents. No one switches from Slack to your half-built version regardless of how clever the differentiator is.
- Hardware-software hybrids. Hardware iteration cost is too high to MVP loosely.
- You are not the user. If you don't viscerally understand the problem, an MVP gives you no signal, you can't tell if it's working.
For these cases, the better mental model is "Minimum Lovable Product", the smallest scope that a target customer would feel proud paying for. Not lean, not bloated. Lovable.
Side-by-side: same idea, two budgets
To make this concrete, here's what the same B2B SaaS idea (a team workflow tool) looks like at the two extremes, based on real quotes we've issued:
| Scope | MVP version | Polished v1 |
|---|---|---|
| Designed screens | 5 | 22 |
| Auth | Email + password | + Google SSO + magic link |
| Multi-user | Single user only | Workspaces + roles |
| Onboarding | None, drop into empty state | Guided flow + sample data |
| Integrations | None | Slack, HubSpot, Zapier |
| Mobile | Responsive only | Responsive + native iOS |
| Build cost | $22,000 | $110,000 |
| Time to launch | 7 weeks | 4.5 months |
The cost delta is 5x, the time delta is roughly 3x. Whether the MVP is the right answer depends entirely on whether your target buyer would pay for the MVP version. If yes, start there. If no, you'll burn $22k confirming what a 30-minute customer interview would have told you.
The "manual MVP" most founders skip
Before any code is written, the cheapest validation experiment is a "concierge MVP", you doing the work manually that the eventual product will automate. Sales recruiting platforms started as founders manually matching candidates and clients via spreadsheet. AI-powered SaaS companies often start as "you email us, we run the model and email back the results", no UI at all. First Round Review documents this pattern across dozens of post-mortems and founder interviews.
The concierge phase is the highest-ROI two weeks any pre-product founder can spend. It validates demand, refines the workflow, and produces real testimonials, none of which require a single line of code.
The framework: 4 questions to decide
- Can a target buyer pay you for the MVP version as-is? If no, go polished or go manual.
- Will your buyer's purchasing process require features the MVP excludes? (SSO, audit logs, security questionnaire?) If yes, go polished.
- Are you in a regulated industry where shipping requires substantial fixed compliance cost? If yes, the MVP/full delta shrinks dramatically; consider going polished.
- Are you the user, or do you have at least 10 prospective users committed to giving feedback weekly? If neither, pause building, go talk to people first.
Real cost data from the failure rate
According to CB Insights' top reasons startups fail analysis, "no market need" remains the #1 cause across 100+ post-mortems studied. The startups that died with "no market need" had, almost universally, built first and validated demand second. The MVP advice exists because of this. The reason it's misapplied is that founders interpret "build small" as the goal, when the actual goal is "validate demand cheaply."
An MVP that doesn't validate demand is just a small expensive thing. A one-page sales site with a real $1 charge button can validate demand better than three months of MVP development.
What to ship if you go MVP
- One core workflow, end-to-end, that actually works
- Auth (just email/password, skip social login at this stage)
- Stripe checkout for the paid plan
- One support email that goes to the founders
- A Loom video onboarding instead of a built-in product tour
- Manual ops behind the scenes wherever automation is expensive
What to skip ruthlessly: admin dashboards, advanced settings pages, dark mode, native apps, internationalization, complex permissioning, analytics dashboards beyond a basic event log. All of these can wait six weeks.
What to ship if you go polished v1
- 15, 25 designed screens with empty states and error states
- Multi-user accounts + at least basic roles
- Onboarding flow with sample data
- 2, 4 high-leverage integrations (the ones your buyers list as "must-have")
- API and webhooks even if usage will be light initially
- Public status page and at least one SLA tier
- Customer-facing changelog
For the budgeting math behind both routes, our deep dive on SaaS development cost in 2026 breaks down line items.
The hybrid: MVP scope with polished UX
The third way most teams should consider: build a narrow scope (MVP-style) but invest in polished UX on the screens you do have. This is the "minimum lovable product." Costs are 1.3-1.7x an MVP, not 5x a full v1, and you avoid the "looks unfinished" stigma that kills early demos. For most B2B founders this is the right answer.
Working with DevEntia
We help founders pick the right scope at the right moment, and then ship it. Whether that's a $22k MVP, a $110k polished v1, or a $300k enterprise build, the conversation starts the same way. Tell us about your project and we'll spec out a scoped plan in the first call.