What an MVP actually is (and isn't)

Minimum Viable Product has become a permission slip to cut corners. Founders use it to justify shipping half-thought software, investors use it to justify not funding full features, and development companies use it to lowball proposals. None of that is what the term means.

The original definition from Frank Robinson and Steve Blank: an MVP is the smallest thing you can build that lets you test a critical business hypothesis you couldn't test any other way.

Two things make this precise: it focuses on learning, not shipping, and it requires you to articulate the specific hypothesis being tested. Most "MVPs" fail this test because the hypothesis is vague — "people want our product" is not a hypothesis, it's a hope. A real MVP hypothesis is falsifiable. You know what you'd see that would prove it right, and what you'd see that would prove it wrong.

MVP doesn't mean "build it cheap." It means "solve for learning, not feature completeness." The constraint is what you can learn, not what you can afford to build. An MVP that answers your core question is worth ten features that don't.

If you can't articulate what you're trying to learn, the MVP itself isn't the problem — your product strategy is. A vague MVP is a symptom of a vague vision. Go back to first principles before you write a line of code.

When you need an MVP vs. a full product

The decision isn't "should we build an MVP?" — it's "what kind of evidence do we already have, and what's missing?"

You probably don't need an MVP if:

  • You have strong evidence from customer interviews. If you've talked to 50 potential customers, gotten consistent demos before you built anything, and have a waitlist — you may be past the point where an MVP teaches you something new. You need execution.
  • The problem is well-understood and the solution is obvious. You're building a known thing in a new vertical. The technology isn't novel. Go straight to a proper product.
  • You're building an internal tool. There's no market risk, only execution risk. No reason to build a prototype when you can build the real thing.

You probably do need an MVP when:

  • The core assumption hasn't been validated through conversation or evidence
  • You're entering a market where behavior is hard to predict
  • The technical approach is novel or has uncertain feasibility
  • You're raising on a thesis rather than on traction

The build-vs-buy decision for MVP: If you're a technical founder, the internal build vs. agency decision hinges on one question — is your team's highest and best use writing code at a startup's pace, or do you need strategic guidance alongside execution? For non-technical founders, the math often points toward a partner with both. Our fractional CTO service is built for exactly this stage.

The 5-step MVP development process

  1. Define the learning goal before the feature list

    Write down the single question this prototype needs to answer. Not "will people use our product" — that's too big. Something like: "Will doctors change their workflow to use a symptom checker that runs on their existing EHR?" The feature list follows the question, not the other way around. Everything that doesn't serve the learning goal gets cut.

  2. Set measurable success criteria

    Decide in advance what "pass" looks like and what "fail" looks like. Vague success metrics lead to post-hoc rationalization — "well, we got some signups, so maybe it's working." Pick a number. "If 20% of beta users complete the core workflow twice in the first week, we have signal. Below 5%, we don't." This removes the ambiguity that kills learning cycles.

  3. Map the technical scope to the learning goal

    Take the feature list and identify what needs to actually work versus what can be manual, mocked, or omitted. In most MVPs, 60–70% of what founders think they need for the prototype doesn't serve the learning goal. Authentication systems, admin panels, email workflows, payment integrations — all of these can often be replaced with a spreadsheet and a Slack channel for the MVP phase. The tech debt is fine. The scope creep isn't.

  4. Build in weekly learning sprints, not milestones

    Traditional project management produces a spec, then builds, then tests. MVP development should produce a spec, build something small, learn from it, then decide whether to build more. The sprint cadence matters — weekly check-ins force honest assessment of progress. If two weeks pass without any evidence being generated, the scope was wrong. Cut features, not timelines.

  5. Decide what happens after the data comes in

    Before the build starts, agree on what you'll do with the results. If the MVP validates the hypothesis, what's the next milestone and who owns it? If it doesn't, is the plan to pivot, kill the idea, or iterate? This decision sounds obvious. It almost never happens. The result is founders who spent 12 weeks on a prototype and can't bring themselves to kill it even when the data says they should.

Common MVP mistakes that kill startups

1 Building the wrong scope (and calling it "MVP")

The most common failure mode. Founders discover a feature during development and add it "because we're already building." The prototype accumulates scope until it looks more like a v1 than a learning tool. By the time the build is done, two months have passed and you still haven't learned what you needed to. Scope management isn't a one-time decision — it's a weekly discipline.

2 Skipping customer discovery before building

Every week you spend building without talking to a potential user is a week of risk you're not managing. The discovery conversation isn't a nice-to-have before an MVP — it's the prerequisite for knowing what the MVP should test. We work with a lot of companies that had strong initial feedback before building. We very rarely work with companies that say "we built it without talking to anyone first and it worked."

3 Building for investors instead of users

If the MVP is designed to impress a VC rather than teach you something, you will optimize for the wrong things. Investor-facing prototypes tend to get polished features that users never see while missing the friction points that matter in actual use. Decide who you're building for before you start. If it's investors, don't call it an MVP — call it a demo. If it's users, strip everything that doesn't serve their experience.

4 Letting MVP code become production code

MVP code is written fast, under incomplete information, with temporary solutions for hard problems. That's fine — it's a learning tool, not a product foundation. But if the code you're building becomes the foundation of your actual product without a rewrite, you've baked in technical debt that compounds every future sprint. This is the one that costs the most to fix later. If the MVP produces signal worth acting on, treat it as a prototype and plan the proper build.

5 Building longer than your learning cycle

The whole point of an MVP is speed. If it takes six months to build, you've consumed most of your runway on an unvalidated hypothesis. The timeline pressure is actually the constraint that keeps the scope honest. When time is short, you cut everything non-essential. That's the feature. When time is long, you add features because you can. If you're past the three-month mark on an MVP and still in build mode, something has gone wrong in the scope management. For custom software development decisions at this stage, the architecture choice matters — the right dev partner will push back on scope instead of building indefinitely.

How to choose an MVP development partner

The right partner for an MVP is not the same as the right partner for a full product build. For an MVP, you need someone who thinks in learning cycles, not feature completions. Someone who will push back on scope and argue for cutting things, not adding them. Someone who understands that "it works" and "it answers your question" are different outcomes.

Red flags in an MVP development company:

  • Guarantees "everything" in the first phase. A real MVP partner will tell you what they'll learn in the first sprint, not what features they'll ship.
  • Proposes building the full product first. If they're not pushing for the narrowest possible scope, they may be padding the proposal.
  • Skips the discovery conversation. If they want to start coding before understanding what you're trying to learn, they're a dev shop, not a product partner.
  • Fixed timeline with no contingency for scope changes. Real MVPs need room to cut scope. If the timeline is locked with no mechanism for reducing scope, you lose the adaptive advantage the MVP model is supposed to provide.
  • Long-term contracts before you've validated anything. Month-to-month or sprint-based commitments are the right structure for an MVP engagement.

What to look for:

  • Asks what you're trying to learn, not just what you want to build
  • Proposes a narrower scope than you expected — and explains why
  • Has a process for weekly check-ins with clear learning milestones
  • Gives honest timelines, including contingency for unexpected complexity
  • Has worked with startups at the pre-Seed to Seed stage before

What you're actually buying with an MVP partner: Not just execution. You're buying the discipline to cut scope, the honesty to tell you when your hypothesis is weak, and the speed to generate learning before your runway runs out. The fastest way to evaluate a partner is to ask them to describe what they'd cut from your current feature list and why. Anyone who can't answer that question is not thinking in learning cycles.

Building with Simon3M Group

Our approach to MVP development combines a fractional CTO who understands product strategy with a dev squad that ships at startup pace. This combination matters for the discovery phase because the strategic oversight — someone who can evaluate whether you're building the right thing, not just building it correctly — is what's typically missing from pure execution shops.

The engagement structure is straightforward: a 30-minute call to understand your current hypothesis and evidence, a 48-hour proposal delivery, and week-one sprint kickoff. We work with founders at a specific stage — someone who has done early customer discovery, has a clear problem thesis, and needs a partner who can move fast without producing architectural debt they'll have to pay off later.

If you're pre-Seed and exploring, Seed and moving from prototype to product, or Series A and building out the engineering function — we can probably help. We're direct about what we can and can't do: if an MVP isn't the right move for your stage, we'll tell you. That's part of the service.

If you're earlier than that — pre-discovery, pre-conversation, pre-anything — the right first step is not an MVP. Talk to potential users first. Everything else follows from that.