The most expensive sentence in product development is "while we're at it". We have watched more MVP budgets die from scope accretion than from bad engineering, missed estimates and framework choices combined. This post is the subtraction method we use to hold the line — and the two features we insist on adding that founders almost always try to cut.
The core question: what is the riskiest assumption?
An MVP is not a small version of the product. It is an experiment designed to test the single assumption that, if wrong, kills the business. Everything in scope either serves that test or it waits.
Write the assumption down first
Before any feature list, we make founders complete one sentence: "This business works only if ______." Only if restaurants will pay for direct ordering. Only if field engineers will actually log jobs on their phones. Only if parents trust an app with pickup schedules. The MVP's job is to make that blank measurable — nothing else.
Sort every feature against it
Each proposed feature gets one of three labels:
- Proves it — directly generates evidence about the core assumption. Builds now.
- Supports it — needed for the proving features to function. Builds now, at minimum viable depth.
- Assumes it — only valuable if the assumption is already true. Waits, however obvious it feels.
Referral programs, admin analytics, multi-language support, native apps alongside the web app — nearly all of it lands in the third pile. The third pile is not rejected; it is sequenced behind evidence.
The two things founders always try to cut
The subtraction method has two exceptions — features that look like polish but are actually part of the experiment's instrumentation.
Onboarding. If users never reach the core loop, the experiment produces no data. A confusing first five minutes doesn't fail visibly; it fails as silence, and silence gets misread as "the market said no".
Event tracking. An MVP without analytics is a coin flip you paid five figures for. We wire the funnel events in the first sprint — not a dashboard suite, just enough to answer "where did they stop, and how many made it?"
An MVP that can't tell you why it failed has to be rebuilt just to fail more legibly. That is the most expensive outcome available.
What this looks like on a real timeline
A subtraction-scoped MVP typically lands in six to nine weeks: one to two weeks of discovery, four to six of build, one of hardening. The feature list at the end is shorter than the founder's original — usually by more than half — but every item on it earns its place against the assumption test, in writing, before we estimate a single line of code.
The document that falls out of this process is a scope contract both sides can point at when "while we're at it" shows up mid-build. It always shows up. The difference is whether there is something to point at.
If you have an idea and a deadline, bring us the one-sentence assumption — the scoping session that follows is the cheapest insurance you can buy on the build.