How to validate a startup idea with an MVP

Most early-stage products fail for the same reason: they are too big and too unfocused to learn anything from. An MVP is not a small product. It is the smallest product that lets a real customer give you a real signal.

Start with the decision, not the idea

Before you scope a single feature, write down the business decision the MVP needs to make easier. Will customers pay for this? Will operators adopt it? Will we keep building this category? If your MVP cannot answer one of those, it is too vague.

Pick the smallest credible scope

We use a simple test: if removing a feature would not change the business decision, that feature is not in the MVP. Auth, billing, analytics, and one core flow done well almost always beats five flows done loosely.

Ship in weeks, not quarters

• Week 1: discovery, scoping, and a clickable design.
• Weeks 2–4: build the core flow with production-grade infrastructure.
• Weeks 5–6: hardening, instrumentation, and launch with a small cohort.
• Post-launch: a 30-day window to learn before deciding what to build next.

Instrument what matters

An MVP without instrumentation is a guess. We bake event tracking into the first build so you walk out of the launch window with answers, not opinions: activation, retention, and the one or two conversion events that matter.

What we have learned the hard way

Founders consistently underestimate how much speed comes from cutting scope, and overestimate how much demand a great idea creates on its own. The teams that win are the ones that pick a sharp question, build the smallest thing that answers it, and act on the answer.