If you're talking to developers about an MVP, you've probably already heard the term used three different ways:

"A scrappy prototype to test whether anyone wants this."
"A thin first version we ship to early customers."
"All the features I think I need, just simpler."

Number three is where most founders blow their budget. Let's talk about why.

The Real Definition

An MVP — Minimum Viable Product — is the smallest thing you can build that produces a real, measurable signal about whether your idea works.

That's it. The smallest thing. The signal is the goal — not the product.

If your MVP doesn't have a clear question it's answering ("will people pay for this?", "will users return after week one?", "can we acquire customers under $X?"), it's not an MVP. It's a v1.

The Test: What Are You Trying to Learn?

Before scoping, write down the single biggest question your business is staking on. Examples:

"Will plumbers actually pay $99/month for this scheduling tool?"
"Can solo therapists run their entire intake process through one app?"
"Will people share their financial data with us in exchange for these insights?"

Then build the thinnest possible thing that answers it.

If the question is "will people pay" — you don't need a settings page, a forgot-password flow, social login, dark mode, or an admin dashboard. You need a landing page, a signup, the core action, and a payment button. Often that's 4–6 weeks of work, not 6 months.

How Long Should It Actually Take?

Honest ranges for a real MVP:

4–8 weeks — Single core workflow. One user type. Stripe checkout. Email-based "support." This is most MVPs.

8–14 weeks — Two user types interacting (marketplace, two-sided platform), or complex domain logic (healthcare, fintech, scheduling).

14+ weeks — You're not building an MVP anymore. You're building a v1. That's a different conversation, with different funding implications.

If a developer quotes you 6 months for an MVP, ask which features could be cut to make it 6 weeks. If the answer is "none" — your scope is wrong.

The Features You Don't Need (Yet)

Universally cuttable from MVPs:

Forgot password (use magic links)
Email verification (defer it)
Admin dashboards (run admin from your database GUI)
Multi-tenancy (one user type for now)
Onboarding flows (do this manually for the first 20 users)
Settings pages (defaults are fine)
Notifications (email is fine; in-app can wait)
Mobile apps (responsive web is fine for now)

Every one of these features feels essential when you're staring at competitor screenshots. None of them are essential to the question your MVP is supposed to answer.

The 20-Customer Rule

Build to 20 customers. Not 200. Not 2,000.

Twenty customers can be onboarded by hand. They can email you when something breaks. They forgive rough edges in exchange for early access. They tell you what to build next — and what they hate, which is often more useful.

Most of what people add to MVPs is infrastructure for the thousand customers they don't have yet. Build for the twenty you can actually get this quarter, and let the rest reveal itself.

The Hard Part

The hard part of an MVP isn't building it. It's deciding what not to build. That's a strategy problem, not a development problem — and it's where founders need the most pushback from their developer.

A good development partner will argue with you about scope. A bad one will quote whatever you ask for and disappear when the timeline slips.

If you're scoping an MVP and want a sanity check on what to cut, we'll talk through it for free.