← All articles Build the Right Thing

Minimum Viable Product: Build Less, Learn Faster

By the FabricLoop Team  ·  May 2026  ·  9 min read

The term "MVP" has been used so often and so loosely that it has almost lost its meaning. Founders use it to describe polished v1 launches, rough prototypes, landing pages, and everything in between. Some use it as an excuse to ship something broken. Others use it as a reason to keep building forever ("it's not viable yet").

The original definition — from Eric Ries's Lean Startup — is precise: the MVP is the version of a product that allows you to collect the maximum amount of validated learning about customers with the least effort. It is a learning tool, not a product launch.

The word that matters most: viable

Minimum is not the hard part. Founders are naturally inclined to subtract features. The hard part is viable. A viable product delivers enough value that someone will actually use it and give you honest feedback — or ideally, pay for it.

An MVP that nobody uses teaches you nothing. A landing page with an email signup tells you people are interested in the concept, not whether your solution actually solves their problem. A broken prototype that crashes in the first minute is minimum without viable.

The common mistake Building the minimum version of what you imagined, rather than the minimum version that delivers the core value to a specific user. These are not the same thing. The first is arbitrary; the second is disciplined.

The MVP is a hypothesis test

The best way to think about an MVP is as an experiment with a clearly stated hypothesis. Before you build anything, write down:

Hypothesis structure for any MVP
Assumption
"We believe that [customer segment] wants [outcome] because [reason]."
Test
"We will build [minimum thing] to test whether they [specific behaviour] within [timeframe]."
Signal
"We will know this is true if [measurable outcome] — and false if [the opposite]."

If you can't state a clear false condition, you're not testing a hypothesis — you're building a product. The MVP only works if you commit in advance to what a "no" looks like.

"An MVP without a falsifiable hypothesis is just a product with low quality. That's not the same thing."

The MVP spectrum: from fake to functional

MVPs exist on a spectrum from fully manual to fully automated. Where you should sit on that spectrum depends on what you're trying to learn and how much you're willing to invest in the test.

MVP fidelity spectrum
Concierge Deliver the value manually. No software. Learn if the outcome matters before automating.
Wizard of Oz Show users a working interface; fulfil it manually behind the scenes. Tests demand without infrastructure.
Prototype A clickable mockup or basic functional version. Tests usability and flow, not full reliability.
Functional MVP Deployable product with core feature only. Tests real usage, retention, and willingness to pay.

Many founders skip straight to "functional MVP" because it feels most legitimate. But a concierge MVP — manually delivering the service for 10 customers — often teaches you more in two weeks than six months of building. The goal is learning, not the product.

What belongs in an MVP and what doesn't

The scope decision is where most MVPs go wrong. Here's a framework for what to include:

Include in MVP
  • The single action that delivers the core value
  • Enough UX to make that action discoverable
  • A way to capture payment or commitment
  • Minimum viable trust signals (privacy, security basics)
  • A path to give feedback
Cut from MVP
  • Edge cases and error handling for rare scenarios
  • Settings, preferences, and customisation
  • Advanced reporting or analytics dashboards
  • Integrations (unless core to the value prop)
  • Onboarding for scale — just call your first users

The test: for every feature you're considering adding, ask "what learning does this enable?" If the answer is "none — it's just better," cut it. Build it later, after you've validated that the core is working.

The difference between an MVP and a beta

These are not the same thing and conflating them causes problems. An MVP is an experiment designed to validate a hypothesis. A beta is an early version of your intended product that you release for testing before general availability.

An MVP might be completely thrown away after the experiment. A beta is typically the foundation of what you'll ship. An MVP is designed to maximise learning per unit of effort. A beta is designed to find bugs in a near-complete product.

You can have an MVP before you ever write a line of code. You cannot have a beta without a largely-built product.

How to know if your MVP worked

Return to your hypothesis. The MVP "worked" not if people said nice things, but if they did the specific behaviour you predicted. Compliments are not validation. Commitments — time, money, repeated use — are validation.

Three signals that your MVP validated the hypothesis:

Three signals it didn't:

The "would you pay for this?" test If you're unsure whether feedback is real, ask directly: "Would you pay $X/month for this?" Then stop talking. The pause that follows is the most revealing data point in early-stage product validation.
How FabricLoop supports the MVP process The MVP phase generates a flood of feedback — user interviews, session notes, survey responses, team debates. FabricLoop keeps your hypotheses, test results, and synthesis in one thread, so the team can see what you learned and why you made the calls you made, even months later.

10 things to take away from this article

  1. The MVP is a learning tool designed to test a specific hypothesis — not a low-quality product launch.
  2. "Minimum" is not the hard part — "viable" is. Something nobody uses teaches you nothing.
  3. Write the hypothesis before you build: assumption, test method, and what a "no" looks like.
  4. A concierge MVP (fully manual delivery) often teaches more in two weeks than six months of building.
  5. A Wizard of Oz MVP shows a working UI but fulfils it manually — tests demand without infrastructure.
  6. Include only what delivers the core value and captures commitment; cut everything else.
  7. An MVP might be discarded entirely after the experiment — that's fine and expected.
  8. Compliments are not validation; return visits and payment are.
  9. If you had to explain why it was useful before users got it, the value proposition needs work.
  10. "Would you pay $X for this?" — and then silence — is the most revealing question in early product validation.