The MVP should prove value, not ambition

The ambition trap

Founders often ship an MVP that is really a phase-one roadmap in disguise: multi-tenant auth, three integrations, and a settings page nobody has asked for. It feels responsible. It delays the only question that matters: will anyone change behavior because this exists?

An MVP is not a moral license to build half of v2. It is an experiment with a falsifiable outcome.

Smallest proof that somebody cares

Proof looks different per product: a paid pilot, a waitlist that converts to calls, a manual workflow behind a simple form, or ten users who return without you nagging them.

If you cannot state the proof in one sentence, you are still decorating.

What to cut first

Cut everything that makes you feel like a “real” product but does not change the proof: brand polish, edge-case admin, second and third roles, analytics dashboards with no decision attached.

Keep the path that lets a stranger complete the core job once—and lets you observe whether they would do it again.

How to apply it

• Write the proof sentence before you write code: “We will know this works when ___.”
• Set a time box; if proof is not visible, change the hypothesis—not the stack.
• Add scope only after proof, and only if it unlocks the next learning.
• Treat “users liked the demo” as weak evidence; look for repeat use or money.