From idea to MVP: a pragmatic playbook

Every founder we meet has more ideas than runway. The job of an MVP isn't to express all of them — it's to test the single riskiest assumption your business depends on, as cheaply as possible.

Start with the riskiest assumption

Before scoping features, name the one belief that, if wrong, sinks the product. Will people pay? Will they switch from the tool they already use? Can the core workflow actually be automated? Your MVP should be the smallest thing that answers that question with real users.

Cut ruthlessly, then cut again

A useful exercise: list every feature, then ask of each, "If we shipped without this, would the core test still be valid?" Most features fail that test. Auth, settings, dashboards, and admin tools can almost always wait.

What survives is usually a single, polished workflow — done well enough that users trust it.

Build for learning, not for scale

An MVP's codebase should be clean but not over-engineered. Pick boring, well-understood technology. Instrument it so you can see what users actually do. Optimize for the speed of your next decision, not for a million users you don't have yet.

Scale when the assumption is validated — not before.