Getting MVP scope wrong is the most expensive mistake available to a founder, and it is nearly always the same mistake: the word is used loosely, the budget is set as though it were used precisely, and the result is a product too big to be a test and too small to sell.
An MVP is the smallest thing that tells you whether you are wrong. That is the entire definition, and everything below follows from taking it literally.
Start from the assumption, not the feature list
Every new product rests on one assumption that would sink it if it were false. Not a list — one. Usually it is something like: people with this problem will change how they work to solve it. Or: this group will pay rather than continue tolerating the thing. Or: we can acquire these customers for less than they are worth.
Write yours down in a sentence. If you cannot, that is the first piece of work and no amount of building substitutes for it.
Then the scoping question becomes mechanical: what is the least we can build that produces real evidence about that sentence? Not a demo that impresses people, and not a prototype nobody uses in anger — something a real user does real work in, because only that produces evidence.
For most products the answer is one workflow, done properly, for one kind of user. Everything else is deferred, and deferred is not the same as cancelled.
The five things that can almost always wait
Self-service billing. Ten early customers can be invoiced by hand. It is a few minutes each and it puts you in conversation with them, which at this stage is worth more than the automation. Billing is also, reliably, the most underestimated component in any product budget.
Configurable permissions. Two hard-coded roles will carry you a long way. Permissions that administrators configure themselves is a subsystem with its own interface and its own support burden, and it is almost never what the early assumption depends on.
The admin panel. You can run queries directly for the first months. It feels unprofessional and it costs nothing, and a surprising number of teams build an entire internal tool before they have ten customers to administer.
Settings. Every setting is a decision you are declining to make, plus a permanent branch through the product. Pick the sensible default and let a customer complaining be what promotes it to a setting.
Onboarding flows and empty states. With ten users you can onboard each one personally, which also teaches you exactly where they get stuck. That knowledge is what makes the automated version good later.
The things that cannot wait, and are cut anyway
Anything that touches trust cannot be deferred. Authentication done casually, data that leaks between customers, a password reset that does not work — these are not rough edges, they end the relationship with the users you spent everything to acquire.
The core workflow cannot be rough either. If the one thing your product does is tedious or unreliable, you will learn nothing about your assumption, because users will leave for reasons unrelated to whether they wanted it. A narrow product that works beats a broad one that stutters, and that is the trade the whole method rests on.
And you cannot defer measuring. If the build ships without any way to see whether people completed the workflow, you have spent the money and bought no evidence, which is the only genuinely unrecoverable version of this mistake.
How to tell you have scoped version one by accident
Some reliable signals. The feature list has more than one type of user on it. There is a dashboard. Somebody has said the phrase "it needs to be scalable" about a product with no users. There is an integration with a system you do not yet have customers using. Or — the clearest one — you cannot describe the whole thing in two sentences without saying "and".
None of these means the plan is bad. They mean the plan is version one, and it should be budgeted, staffed and timed as version one rather than as a cheap experiment. The damage comes from the mislabelling, not from the ambition.
What happens after the evidence arrives
Expect to be partly wrong, because that is the point. The common outcome is not that the assumption fails outright but that it holds for a narrower group than you imagined, or holds for a different reason than you expected. Both are enormously valuable and neither is available from a plan.
This is also why building it cheaply matters beyond the money: a small build is one you are willing to change. Teams that spend everything on the first version defend it long after the evidence has stopped supporting it, because abandoning it means admitting to the spend.
Build the smallest honest test, keep enough budget to act on what it tells you, and treat the roadmap as a set of hypotheses rather than a plan. If it would help to have someone argue with your scope before you commit to it, that is what the free teardown is for — it frequently comes back recommending less than you asked for. How we take products from that point onwards is described on the SaaS page.
