A minimum viable product is not a smaller version of your full product vision. It is the smallest thing you can build and put in front of real users that tests whether your core assumption is true, that people actually want this, will pay for it, or will use it the way you expect.
Getting this wrong in either direction is expensive: build too little and you learn nothing useful; build too much and you've spent months and a large budget before finding out the core idea doesn't work.
Step 1: Identify Your Riskiest Assumption
Before scoping any feature, write down the single assumption that, if wrong, kills the whole product. Usually it is not a technical risk, it is a demand risk ("will people actually use this instead of what they use today") or a behavior risk ("will they do the specific action our business model depends on").
Everything you build for the MVP should exist to test that one assumption. Features that don't contribute to testing it belong in a later phase, however useful they seem.
Step 2: Design the Smallest Real Test
This is often smaller than founders expect. If your core assumption is "businesses will pay for automated invoice reconciliation," you may not need a polished dashboard, multiple integrations, and a full onboarding flow, you may need one working integration, one clear output, and a handful of real users willing to try it.
Manual steps behind the scenes are fine at this stage. If a human doing part of the work manually lets you test the core assumption faster and cheaper than fully automating it, do that first, automate once you know the assumption holds.
Step 3: Define What "Validated" Looks Like Before You Build
Decide in advance what result would tell you the assumption is true, and what result would tell you it is false. Without this, it is easy to rationalize any outcome as encouraging, which defeats the purpose of testing at all.
Common MVP Scoping Mistakes
Building for scale you don't have yet, enterprise-grade infrastructure, multiple user roles, extensive admin tooling, before you know anyone wants the core product. Adding features because competitors have them, rather than because they test your assumption. And skipping real users entirely, testing only with friends or team members who won't give you an honest signal about a product they didn't choose to use.
For every feature on your MVP list, ask: "if we removed this, would we still learn whether our core assumption is true?" If yes, cut it for now.
What We Build
We help founders scope MVPs down to what actually needs testing, not what feels complete, see our Web Application Development page and our Cost to Build a SaaS Product article for related budget guidance.
