How to scope an MVP so it ships

Here is the rule. An MVP is scoped correctly when useable functionality reaches a real user inside six months, it serves one workflow for one type of user, and every remaining feature can be deleted without invalidating the hypothesis being tested. Six months is not a preference. It is the interval the US Office of Management and Budget set for federal software investments — agencies are required to "deliver useable functionality every 6 months" — and when the Government Accountability Office checked how well that was going, roughly half the projects claiming to meet it actually did. Everything else in this article is that one rule, examined.

The rule has three clauses and each does distinct work. **Six months** bounds the labour, because cost is linear in months and nothing else in the plan is. **One workflow, one user type** is what makes the build tractable, because scope grows multiplicatively with the number of roles you serve, not additively. **Deletable without invalidating the hypothesis** is the test that actually cuts things, and it is the clause teams skip — because applying it honestly usually removes something someone senior asked for.

**Why the six-month figure is worth borrowing from federal procurement,** of all places. In August 2016 the Government Accountability Office examined how well agencies followed the OMB requirement to deliver useable functionality every six months. Twenty-two agencies reported on the IT Dashboard that 64% of their software development projects would meet it. GAO's own detailed review of seven departments found approximately 50% of projects actually achieved incremental delivery at the prescribed interval, with the discrepancies traced to inconsistent reporting of non-software projects, timing variations, and insufficient documentation supporting claimed delivery. Officials cited management obstacles, organisational barriers and project complexity as the impediments (US Government Accountability Office, Information Technology Reform: Agencies Need to Increase Their Use of Incremental Development Practices, GAO-16-469, August 2016).

Sit with the shape of that finding rather than the politics of it. These are organisations operating under an explicit mandate, with mandatory reporting and an external auditor, and their self-reported increment discipline still overstated the measured reality by fourteen percentage points. A startup with no mandate, no auditor and a board deck to fill is not going to do better by intending to. The lesson is not that six months is hard; it is that the belief you are inside it is unreliable, so the scope has to be small enough that the belief has slack in it.

GAO's guidance elsewhere is blunt about what the alternative produces. Its Agile Assessment Guide, published on 28 September 2020, notes that "all too frequently, agency IT programs have incurred cost overruns and schedule slippages while contributing little to mission-related outcomes," against federal IT spending of over $90 billion annually — which is why IT management sits on GAO's High Risk List. The guide defines the remedy in a way worth quoting to anyone arguing for a bigger first release: "Agile is an approach to software development in which software is developed incrementally and is continuously evaluated for functionality, quality, and customer satisfaction," and it "can reduce the risks of funding a program that fails or produces outdated technology" (US Government Accountability Office, Agile Assessment Guide, GAO-20-590G, September 2020).

"Produces outdated technology" is the failure mode founders underrate. A twelve-month first release is not merely twice the cost of a six-month one; it is a bet that the market question you are asking will still be the relevant question a year from now. In a category moving as fast as anything AI-adjacent currently is, that bet loses more often than the cost overrun does.

**Applying the deletion test, concretely.** Write the hypothesis in one sentence, in commercial terms, before listing any features: *clinics will pay for automated insurance eligibility checks if the check takes under a minute*. Then take every proposed feature in turn and ask what happens to that sentence if the feature does not exist. Multi-user permissions? The hypothesis still tests — one login per clinic is enough to learn whether they will pay. A billing integration? Still tests; invoice by hand for the first twenty customers. A mobile app? Still tests, if the check happens at a desk. Sub-minute eligibility checking? Delete that and there is nothing left to learn. That feature is the MVP. The others are the roadmap, and writing them down as a roadmap is what makes cutting them politically survivable.

Three things always survive the cut, and it is worth naming them so they do not get argued about every time. **Authentication**, because retrofitting identity into a shipped product is more expensive than building it once and there is no honest way to test a paid workflow without it. **The one workflow**, end to end, including the ugly parts — the failure states, the empty states, and what happens when the third-party API is down. And **the instrumentation that tells you whether it worked**, because an MVP that ships without the measurement is an expensive way to generate opinions. Everything outside those three is negotiable by definition.

**The AI-specific trap deserves its own paragraph,** because it is currently the most common way a well-scoped MVP becomes an eighteen-month project. An AI feature is not a feature; it is a scope multiplier, because a non-deterministic component needs an evaluation harness, a defined threshold for a wrong answer, and a human escalation path before it can face customers. Stack Overflow's 2025 Developer Survey measures the cost of skipping that: **66%** of developers name "AI solutions that are almost right, but not quite" as their biggest frustration, **45.2%** say debugging AI-generated code takes longer than writing it, only **4.4%** say AI handles complex tasks very well, and among those asked about agents, **87%** reported concern about the accuracy of agent output (Stack Overflow, 2025 Developer Survey: AI).

The decision rule that follows is simple and unpopular. If the hypothesis you are testing is not itself about the AI, the AI does not go in the MVP. A scheduling product testing whether clinics will pay for automated eligibility checks does not need a natural-language assistant in release one, however much better the demo looks with one. If the hypothesis *is* about the AI — the whole proposition is that a model can do this task acceptably — then the evaluation harness is not overhead you might add later. It is the product, because "acceptably" is the entire question and you cannot answer it without a way to measure.

**A worked example of the rule holding.** An AI virtual seller assistant we built launched as a free pilot for 200 Amazon sellers, integrating one marketplace's data with a privacy-by-design framework and no external data exposure, and was architected to extend to Shopify, eBay, Walmart and TikTok later rather than at launch. One workflow, one user type, one marketplace, a bounded pilot population, and the multi-marketplace ambition written down as a sequence rather than built as a scope. That is the deletion test applied before the first sprint instead of during the third.

**What to do when someone insists on more,** which they will. Do not argue for cutting; argue for sequencing. Take the list nobody will shorten and split it into increment one and increment two, with increment one bounded by the six-month rule and increment two written down in full detail so it visibly still exists. Nothing has been lost, the argument stops being about whose feature matters, and the plan now has a date on it. In practice this reframe succeeds where cutting fails, because it removes the implicit accusation that someone's request was unimportant.

Two failure signals are worth watching for once work starts. If the definition of the first release changes more than once a month, the hypothesis was never written down clearly — go back and write the sentence. And if nobody can say what the acceptance test is, in one sentence, before code is written, then the scope is not a scope, it is a wish list, and a fixed price against it will become a change order within three weeks.

This is the same discipline behind fixed-scope integration sprints: a named capability, a defined deliverable, and a defined end rather than an open-ended discovery meter. It is also why a scoping conversation is worth more than a rate negotiation — what an MVP build actually costs does the labour arithmetic that makes the six-month rule a budget rather than a slogan, and a virtual seller assistant piloted with 200 sellers shows the shape it produces. For first releases that genuinely turn on a model doing the work, the verification layer that top SaaS development company require at scale applies at MVP scale too, just smaller: one workflow, one threshold, one escalation path, measured from day one.