What Is an MVP? A Practical Guide for First-Time Founders

"MVP" gets thrown around so often it's lost precision. An MVP — Minimum Viable Product — is not a half-finished app, and it's not the cheapest possible version of your full vision either. It's the smallest thing you can build that lets real users validate or invalidate your core assumption. Getting that definition right is the difference between an MVP that teaches you something and one that just delays the real work.

What an MVP Actually Tests

Every product idea rests on a core assumption: that people have this problem, that they'll pay to solve it this way, that this specific workflow is what they need. An MVP's entire job is to test that one assumption as cheaply and quickly as possible — not to demonstrate every feature you eventually plan to build.

What an MVP Is Not

• It's not a prototype — an MVP is used by real customers doing real work, not clicked through in a demo.
• It's not "version 1 with fewer features" — it should be scoped around one core hypothesis, not a trimmed feature list of your full vision.
• It's not an excuse to skip good engineering — sloppy code in an MVP that succeeds becomes expensive technical debt fast.
• It's not free — a real MVP that generates real signal still requires real development investment, just less than the full product.

How to Scope One

• Write down the single riskiest assumption your business depends on
• Design the smallest workflow that would prove or disprove it with real users
• Cut every feature that doesn't directly serve testing that assumption
• Decide upfront what success and failure look like — specific numbers, not vibes
• Build with clean-enough architecture that a validated MVP can evolve, not require a rebuild

A Common Mistake: Building the MVP of the Wrong Thing

Founders often build an MVP of their product when they should be building an MVP of their business model — testing willingness to pay before testing feature completeness. If people won't pay for a rough version, a more polished version rarely fixes that. Test the riskiest assumption first, whatever it is.

We've built MVPs that raised funding and MVPs that correctly told founders to pivot before they spent another six months building the wrong thing — both are a win. If you want a second opinion on what your MVP should actually test, that's worth a conversation before a single line of code.