What is an MVP?

Where the term came from

Frank Robinson coined the term in 2001, but it entered the founder vocabulary through Eric Ries and the Lean Startup movement around 2011. The original idea was disciplined and useful: build the smallest thing that delivers actual value, ship it to actual users, and let the data decide what comes next. Over the next decade the term got diluted into meaning "anything you launch before the polished thing" — which is how teams end up with six-month MVPs that are neither minimum nor viable.

The minimum and viable both matter

Most MVP failures come from honoring one of those two words and ignoring the other. "Minimum" without "viable" produces clickable wireframes that prove nothing, because they cannot be used to do work. "Viable" without "minimum" produces an eighteen-month build that is really a v1.0 dressed up in MVP clothing — by the time it ships, the team is too invested in the assumptions baked into it to change anything.

A healthy MVP is uncomfortable for everyone involved. The founder feels like the product is embarrassingly limited. The engineers worry about the corners they cut. The first users hit rough edges. That discomfort is the price of the learning loop being fast.

The MVP scoping rules we actually use

Pick exactly one user persona. If you cannot describe the primary user in one sentence, you have not picked yet. Pick exactly one workflow that ends in measurable value — closing a deal, scheduling an appointment, generating a report. Cut every feature whose absence does not break that workflow. Charge for it from day one even if the price is small. And instrument everything: which buttons get clicked, which screens get abandoned, which features get used twice and never again. Without instrumentation you have shipped a product, not an MVP.

What an MVP is not

An MVP is not a prototype — prototypes show ideas to investors, MVPs deliver value to users. It is not a "phase one" with phases two through five already designed — that is just a regular product with the painful parts deferred. And it is not free-forever — anything that does not produce honest pricing signal is a hobby, not an MVP.

At QUANT LAB

We ship MVPs in 8 to 12 weeks for founders who have validated demand and need to move fast. Our custom business software work starts with a one-week scoping sprint where we cut the proposed feature list roughly in half — not because we are cheap, but because every unshipped feature is one less thing slowing your first ten conversations with customers. The technical stack defaults to Next.js, Postgres, and Stripe, with API integrations for the third-party services your workflow depends on.

If you are weighing whether to start at all, read our build versus buy framework first — half the MVPs we get asked to build should not exist.

After the MVP — what comes next

Shipping the MVP is the start of the work, not the end. The next 90 days are about converting the first ten paying customers into reference accounts, watching where they struggle, and deciding what to build versus what to kill. Most MVPs need three things before the next stage: retention measurement (does anyone still use it after week four?), a clear next pricing tier, and a backlog driven by usage data rather than founder intuition. Teams that skip this phase end up building v2.0 from the same speculative list of features they had before launch.