Roughly four out of five AI MVPs ship a week-6 feature that does not survive contact with a paying customer. The failure is rarely engineering. The team built the thing they were asked to build, and built it competently. The failure was upstream — a scoping decision made on day 1, in a 90-minute room, by a founder who applied a 2014 SaaS-MVP frame to a 2026 AI product. The feature shipped. The feature was the wrong feature.
This essay names the five recurring scoping mistakes that produce that outcome. For each: what the founder does, why the choice feels right, what ships, the correction. It closes with what an MVP-1 should ship instead — one narrow workflow, one frozen eval rubric, one graceful fallback. A spoke in the broader idea-validation playbook and the idea-to-product manifesto.
Decision Scope
This essay describes a recurring failure pattern observed across AI MVP scoping conversations in 2025–2026, from a builder’s seat at SFAI Labs. The five traps are heuristic, not statistical — named because founders self-recognise them quickly, not because a published study counts them. Use as a self-diagnostic, not a substitute for talking to your engineering partner.
Why this is an AI-specific problem
The classic MVP frame — Eric Ries, early Y Combinator, the lean canvas — assumed something a 2026 AI MVP cannot assume: that the technology behaved deterministically. A SaaS feature either worked or did not. Once it worked, it kept working. Scope discipline was about cutting features to ship faster.
A 2026 AI feature is a different shape. It is probabilistic, it costs per call, it sometimes hallucinates, it depends on a frontier vendor whose model changes under the founder’s feet, and the gap between “demo passes” and “production survives” is the widest gap the industry has seen since mobile. The classic MVP playbook does not address any of that.
Three of the five traps below are pure 2026 problems. Two are old traps that got worse when the product became probabilistic. All five are recognisable from the outside in the first sprint review.
Trap 1: The flagship-feature trap
What the founder does. Picks the single most impressive AI surface in the product as the MVP-1 scope. The pitch deck has a hero screen; the hero screen becomes the build target.
Why it feels right. The hero screen is the easiest thing to show investors, demo on a sales call, and explain at a dinner. Picking it feels decisive — one clear target, one clear demo, one clear story.
What actually ships. A surface that demos well on a hand-picked input and falls apart on the second input a customer tries. The flagship surface is almost always the one with the widest input distribution — open-ended writing, summarisation of arbitrary documents, end-to-end agentic tasks. Wide input distributions need order-of-magnitude more eval coverage to hit a reliable pass rate. The team did not budget that work; they budgeted the demo. By week 6, two of three customer inputs fail and the team is debating whether to ship a “beta label”.
The correction. Pick the most repeatable workflow, not the most impressive surface. The repeatable workflow is narrower, more boring, and easier to defend on a frozen eval set — the reorder-classification flow, not the open-ended brand-voice writer; the contract-clause extractor on a known taxonomy, not the open-ended legal-research assistant. The repeatable workflow ships at production quality in week 6; the flagship surface ships at production quality eight months later, after a rebuild. The smallest-possible-AI-feature framing is the upstream discipline.
Trap 2: The breadth-not-depth trap
What the founder does. Scopes MVP-1 as five small AI features across the product instead of one full-quality feature in one workflow. The roadmap lists “AI summary”, “AI search”, “AI autocomplete”, “AI tagging”, “AI rewrite”. Each gets a week.
Why it feels right. Breadth looks like progress on the roadmap. The investor-deck visual is denser. Internally it feels safer — diversified bets, not a single point of failure.
What actually ships. Five mediocre AI features, each at roughly 70% pass-rate on a charitable eval, no single one at the threshold a paying customer would accept. Paying customers do not renew on 70%-correct AI features. They renew on one feature at 95%+ on a clearly defined slice. Five-at-70 sums to zero paying customers; one-at-95 sums to a renewing customer.
The correction. Pick one workflow, ship it at production quality, instrument it with an eval rubric, and only add the next workflow once the first is durably above its quality threshold. This is the thin-slice prototype discipline applied to MVP-1 scope. Depth in 2026 AI products is the moat; breadth is theatre. The buyer-side mirror — decoding production-ready in AI agency proposals — makes the same point: production-ready means one workflow at quality, not five at demo.
Trap 3: The AI-everywhere trap
What the founder does. Adds a model call to every surface in the product on the theory that any AI is better than no AI. Summarise buttons on the dashboard, the inbox, the report builder. Auto-generated empty states. Rewritten error messages. AI autocomplete on every form.
Why it feels right. It looks like the product is on the AI side of the divide rather than the legacy side. The investor pitch can say “AI-native” without hesitation.
What actually ships. The surfaces that matter — the one or two workflows where the model creates real customer value — get crowded out by ten surfaces where it adds noise, latency, and cost. Users learn to ignore the AI everywhere, including where it would have mattered. Cost-per-active-user climbs. Eval surface area becomes impossible to track because nobody scoped which calls were load-bearing and which were decorative.
The correction. Treat every model call as a load-bearing decision. Each one needs a written justification: what value the call adds, what the fallback is, what the eval rubric is. If it cannot pass that three-question test, it does not ship. The discipline is identical to feature-gating in 2014 SaaS — the difference is the model call carries both a quality risk and a cost-per-active-user risk a deterministic feature did not.
Trap 4: The no-fallback trap
What the founder does. Scopes the workflow with no plan for the cases where the model is wrong. The roadmap row says “AI clause extractor — 6 weeks.” It does not say what happens when the extractor returns something incorrect, or low-confidence, or empty, or refuses to answer.
Why it feels right. During the prototype, the model behaved. Three of three test inputs returned the expected output. The fallback question feels like edge-case engineering — handle it later, after launch.
What actually ships. A workflow that works on the inputs the team tested and breaks visibly on the second day of customer use. The customer sees a wrong answer presented with model confidence, a vague “something went wrong” error, or an empty result that does not explain why. Trust evaporates inside one bad interaction. The team spends weeks 7 through 14 retrofitting fallback logic that should have been scoped on day 1.
The correction. Fallback design is a first-class line item, sized at roughly the same cost as the happy path. Three components: a confidence signal (model-emitted, log-probability-derived, or verifier-derived); a UX state for low-confidence that never presents a wrong answer as a confident one; and a deterministic backstop or escalation route — a search result, a saved template, a human queue. The eval-first build playbook treats fallback design as part of the eval rubric, not as a separate question. That is the correct frame.
Trap 5: The eval-free trap
What the founder does. Scopes the MVP in features and dates — “ship the AI clause extractor by June 15” — with no defined quality threshold. The team writes the feature, runs five informal test inputs, and ships when the calendar says ship.
Why it feels right. Defining the eval before the feature feels like over-engineering. The founder has heard “ship fast, iterate” applied to every prior SaaS MVP. Building an eval set before writing the feature reads as bureaucratic.
What actually ships. A feature with no published quality threshold, which means no published bar for “done”, which means the team calls it done when the calendar runs out. When the first paying customer pushes past the un-scoped quality boundary, neither the founder nor the engineering partner can answer “is this a bug or a known weakness?” Every customer complaint becomes an emergency. By month 3, the team is rebuilding the eval set in retrospect, against complaints rather than against scope.
The correction. Scope the MVP in eval pass-rate, not in feature count. A correctly scoped AI MVP-1 has, on day 1, a frozen test set of 50 to 500 realistic inputs, a written rubric, and a target pass-rate the team commits to before they ship. Below the threshold, the feature is not ready, regardless of calendar. Above the threshold, the team can defend readiness in front of a customer or an investor. The companion editorial-600 piece — stop scoping AI projects in features, scope them in evaluations — argues this for agency engagements; the same logic applies inside a founder’s own MVP plan at smaller scale.
What an MVP-1 should ship instead
The corrected MVP-1, after the five traps are cleared, has a familiar three-part shape. It is the smallest configuration that survives contact with a paying customer. It is also unglamorous, which is why it gets skipped.
One narrow workflow. Not the flagship demo. Not five small features. A single repeatable task in the customer’s daily process where the model adds clear value. Definable in one sentence. Measurable on a held-out test set. Reorder classification, not open-ended brand voice. Clause extraction on a known taxonomy, not free-form legal research. The narrower the workflow, the higher the achievable pass-rate inside the MVP-1 budget.
One frozen eval rubric. A written test set of 50 to 500 realistic inputs, version-controlled, with a written rubric that says what counts as a pass. The rubric was written by the founder and the engineering partner together — not handed off. Pass-rate target is committed before the feature is built. The rubric becomes the artifact the team uses to call the feature ready.
One graceful fallback. A single, designed UX for what happens when the model is uncertain, wrong, or refuses. Confidence signal, low-confidence UX state, deterministic backstop or human-escalation route. Scoped on day 1, sized at roughly the same effort as the happy path. The fallback is what allows the founder to ship at 88% pass-rate instead of waiting for 99%, because the 12% lands gracefully.
Three artifacts, scoped on day 1, defended through week 6. The corrected MVP-1 looks smaller than the original roadmap. It ships at production quality on schedule. The customer renews. The roadmap behind it compounds, because every subsequent workflow bolts onto a foundation that already has an eval rubric, a fallback design, and a customer who trusts the product.
The AI MVP Scoping Worksheet at /lead-magnets/ai-mvp-scoping-worksheet walks a founder through the three-part shape against a specific idea.
FAQ
Are these the only AI MVP scoping mistakes?
No. They are the five most recurrent. Others exist — misjudging cost-per-call at scale, picking the wrong frontier tier, mis-scoping latency budgets — but those are downstream technical decisions, not the day-1 founder-side framing trap. The five above are the ones a non-technical founder can self-diagnose without engineering help.
How is this different from generic MVP scoping advice?
Classic MVP scoping assumed deterministic features. AI MVP scoping has to budget for probabilistic behaviour, eval design, fallback design, and per-call cost. Three of the traps — AI-everywhere, no-fallback, eval-free — do not appear in classic MVP advice because they were not failure modes in a deterministic feature factory. Inheriting 2014 MVP discipline without modification is the meta-mistake.
Which trap is most common in 2026?
The eval-free trap. Most founders have absorbed enough of the “lean MVP” canon to avoid breadth-not-depth, but very few have absorbed the eval-first discipline. The feature ships on a calendar deadline, the quality threshold was never written down, and the team has no language to defend “is this ready?” against a customer complaint.
Do these traps apply to agentic products?
Yes, with one amplification. Agentic products compound error across multi-step plans — a 95% per-step pass rate compounds to roughly 60% across ten steps. The no-fallback and eval-free traps are catastrophic faster. The eval rubric must score end-to-end task success, not per-step.
How small can MVP-1 be and still be useful?
Smaller than founders are comfortable with. The test is whether a paying customer would keep the product running for a quarter on this one workflow alone. If the honest answer is no, the workflow is not narrow enough — it is wrong-shaped.
Does this advice change for internal-use MVPs?
The traps look the same. The correction is gentler. But the eval-free trap is the most punishing for internal MVPs — internal sponsors are quicker to declare the project a failure when there is no agreed quality bar.
How does the corrected MVP-1 connect to PRD writing?
The frozen eval rubric and the fallback design become two named sections of the PRD. The PRD that the idea-validation playbook describes treats both as first-class. A PRD that ships without an eval rubric or a fallback design is the artifact form of the eval-free and no-fallback traps.
Which frontier model assumptions should the MVP scope make?
Test on the frontier tier the team can afford to run in production. Currently that means Claude Opus 4.8 or Claude Sonnet 4.6 from Anthropic, GPT-5 from OpenAI, or Gemini 2.5 Pro from Google for the high tier; smaller bands for cost-sensitive surfaces; Llama 3.3 as the open-weights escape hatch. The scope should pass the eval on at least two — single-vendor dependency is itself a scoping mistake.
What if my engineering partner is pushing for one of the five traps?
Push back with the eval-rubric question. Ask: what is the pass-rate target, on which frozen test set, and what is the fallback when the model is wrong? If the answer is “we’ll figure that out in week 5”, the scope is shaped like one of the five traps regardless of how it is described.
Next step
If the MVP-1 you are about to scope looks like one of the five traps, the cheapest correction is on paper before you build. Spend a week defining the narrow workflow, the eval rubric, and the fallback design. Then build. It is the cheapest week in the entire MVP.
Arthur Wandzel
