The founders who ship a working AI product in 2026 have exactly one narrow AI feature in MVP-1. Not a suite. Not three. One. The cost of running an AI feature in production — eval, observability, fallback, on-call, vendor risk — does not scale linearly with feature count. Two AI features in MVP-1 is rarely 2x. It is closer to 4x. Five is closer to a 16x build that never ships. The only MVP-1 worth scoping is the smallest configuration that survives a paying customer’s first month — and founders systematically scope past that line by three to five times.
Sibling spokes argue the case from different angles: why most AI MVPs ship the wrong thing first names the five scoping traps; stop validating AI ideas with surveys, use a thin-slice prototype instead inverts the validation sequence. The cluster anchor is the idea-validation playbook; the master is the idea-to-product manifesto. The editorial-600 companion is stop scoping AI projects in features, scope them in evaluations.
Decision Scope
This essay is a scoping POV, not technical or financial advice. The compounding-cost figures are heuristics from observed AI MVP engagements in 2025–2026 at SFAI Labs, not a published study. The 6-week / 20-eval / 2-person test is a planning rubric. Treat it as a self-diagnostic to bring into your next scoping conversation.
Why “AI as a suite” is the dominant 2026 founder fantasy
Walk into ten pitch meetings in 2026 and nine describe MVP-1 as a suite. Hero screen: an AI analyst that ingests a data warehouse and answers any business question. Four tiles below: AI summary, AI email draft, AI ticket tagging, AI knowledge search. The founder calls the suite the MVP.
The framing is new. The 2014 SaaS pitch described one feature. Calendly was a scheduling link, Stripe an API for card payments, Notion a notes app. The buyer did not expect a suite at seed. In 2026 the buyer does. Three forces produced the shift: every competitor deck claims a suite, so pitching one feature reads as under-ambitious; the model APIs make it trivially easy to bolt a model call onto any surface; and every frontier-lab keynote shows ten capabilities at once.
The trap is that running an AI feature in production looks nothing like writing one. A model call in a prototype takes an hour. Running it in production — with an eval rubric, observability for drift, a fallback for wrong answers, and an on-call rotation for misbehaviour at three in the morning — takes weeks per surface and compounds across surfaces. The suite pitch is cheap in the deck and expensive in the codebase. Founders who ship the suite at MVP-1 ship five demos with one quality threshold none clears.
Stop describing the product as a suite, even internally. Describe it as one feature. The fact that it sounds small is the signal that it might survive a paying customer.
The compounding cost of features
The standing load of an AI feature is not the code calling the model. It is everything around the call. Five components scale per feature; two compound.
Eval set. Each feature needs a frozen test set — 50 to 500 realistic inputs with expected outputs, version-controlled, with a written rubric. Re-running against every model upgrade is recurring cost per feature. No re-use across features when tasks differ.
Observability. Each feature needs structured logging of inputs, outputs, model identity, latency, cost, confidence, and user reactions. The dashboard is rebuilt once per feature because input distributions and failure modes differ.
Fallback design. Each feature needs a UX state for when the model is uncertain, wrong, or refuses: confidence signal, low-confidence UX, deterministic backstop or escalation. The most consistently under-scoped line item in the engagements we see, and the line whose absence most reliably destroys trust in week 3. Per-feature, costs roughly as much as the happy path.
On-call complexity. One AI feature, one class of pager. Five features, five classes — a tagging model fails differently from a summariser, differently from a reranker. Context-switching between classes during the same shift is itself a tax.
Vendor risk. Anthropic raises a price tier, OpenAI deprecates a snapshot, Google changes a safety filter — every change ripples across every dependent feature. One feature, one migration. Five features, five migrations, often staggered.
Three components — eval, observability, fallback — scale roughly linearly per feature. Two — on-call and vendor risk — compound. If the load at one feature is X, the load at two is rarely 2X. It is closer to 3-4X, because the cognitive switching and migration costs multiply.
Rough math across MVP-1 engagements:
- One feature: load
X - Two:
3-4X - Three:
7-10X - Five:
16-32X
These are not measured numbers. They are the order of magnitude on which teams scoping five features burn out, miss the ship date, or ship five mediocre features none of which clear a customer’s bar. The same reason editorial-600 argued teams should stop scoping AI projects in features and scope them in evaluations — eval pass-rate is the natural unit when the underlying load compounds.
Founders who internalise the compounding produce one-feature MVP-1 roadmaps with a credible MVP-2 plan to add the second once the first is durably above threshold.
The smallest-possible test
The best diagnostic for whether an MVP-1 scope is the right shape is a three-clause question a founder can run on a napkin.
Can one senior engineer plus one founder ship this MVP-1 in six weeks at ≥ 80 percent pass-rate on a frozen 20-input eval set?
One senior engineer plus one founder. Two humans. The engineer writes code, builds the eval pipeline, instruments observability, and designs the fallback. The founder writes the eval set, scores outputs, talks to early customers, and defends scope. If MVP-1 needs more than one engineer, it is wrong-sized — a second engineer adds coordination overhead, separate context, and review cycles that slow a two-person team’s shipping cadence.
Six weeks. Enough to scope, build, instrument, eval, design the fallback, and ship to two friendly paying customers. Not enough to build a suite. A nine-week MVP-1 is almost always a five-feature MVP-1 in disguise.
≥ 80 percent on a frozen 20-input eval set. Twenty inputs is the floor — small enough that the founder can write them in a day, large enough to surface most failure modes. Eighty percent is the rough threshold below which paying customers stop trusting the feature in their first month.
The test fails in three ways. More than one engineer — scope is wrong. More than six weeks — scope is wrong. Cannot hit 80 percent by week six — scope, model, or rubric is wrong. Each failure is a scope problem to surface in week 1, not a quality problem to discover in week 6.
The honest version is sobering. The founder usually cuts the suite to one feature. The demo screen shown to investors is usually not the MVP-1 feature — the MVP-1 feature is narrower and less impressive. The second feature moves to MVP-2 with a written date. It is the cheapest week in the entire program.
What the smallest defensible AI feature looks like, by archetype
The shape varies by domain. Four archetypes recur in our scoping conversations, each over-scoping for a different reason.
The consultant founder. Risk: scoping MVP-1 as “the full consulting workflow, with AI” — a suite. The corrected MVP-1 is the single most repetitive sub-step: the slide-deck-from-notes generator for management consultants, the clause extractor for legal, the model-stress-test for finance. The practice keeps running; the product replaces only the sub-step with the largest billable-hour discount.
The agency owner. Risk: MVP-1 as the full agency workflow with AI on top — never ships, because the workflow is too domain-specific to compress. The corrected MVP-1 is the one piece the agency has done so often that the input distribution is narrow: SEO competitor-research for marketing, brand-style guide drafts for design, interview synthesis for research. The product feeds the agency; it does not replace it.
The ops lead. Senior operations leader with budget for an internal AI product. Risk: MVP-1 as a cross-departmental “internal copilot” — a suite in disguise. The corrected MVP-1 is one workflow inside one team where the manual cost is documented and the eval set can be drawn from existing logs. Support-triage tagging on one product line. Procurement extraction for one supplier class. The narrowness makes the internal-sponsor demo credible at week six.
The domain expert. Senior practitioner — doctor, lawyer, engineer, teacher — building against their own domain. Risk: MVP-1 as “the assistant that does my whole job” — a suite projected from the founder’s mental model. The corrected MVP-1 is the one piece they would willingly delegate to a competent junior: the chart pre-read for a doctor, the deposition-prep brief for a lawyer, the homework-feedback draft for a teacher.
Shared pattern: the smallest defensible AI feature is the single sub-step where the input distribution is already narrow, the quality threshold is known, and the rubric for “done” is legible. MVP-1 does not expand the process. It compresses the narrowest piece of it.
The cut list: 5 things to defer to MVP-2
Five items recur in the cut list across the engagements we run. None belongs in MVP-1.
The admin dashboard. An MVP-1 with two friendly customers needs an internal SQL query and a logs view, not a dashboard. Saves three to four weeks.
The second AI feature. Founders argue for one more “because it pairs naturally.” The pairing argument almost always destroys the eval discipline. Ship the first at 90 percent on its eval, run it for a month, then decide what the data says is next.
The multi-tenant architecture. An MVP-1 with two customers can run two single-tenant instances and let the team learn what the boundary actually needs. Premature multi-tenancy is the most consistent source of month-four rewrites we see.
The custom UI on top of model output. In MVP-1 the output renders into the customer’s existing tool — Slack, Notion, email, their own CRM. The wrapper is an MVP-2 surface and is the second most expensive cut, because it is usually the surface the founder finds most personally compelling.
The analytics and reporting layer. The first two paying customers want the feature to work; they will tell the founder over Slack. The reporting layer is an MVP-3 surface and frequently never gets built.
The personally interesting parts — dashboard, polished UI, multi-tenant, second feature, analytics — are exactly the parts being deferred. That is the signal the cut list is doing its job. MVP-1 is supposed to be unglamorous.
Closing argument
The case for the smallest-possible AI feature is engineering economics, not aesthetics. A five-feature MVP-1 is a 16-to-32x build that rarely clears any single quality threshold in time. A one-feature MVP-1 is a 1x build that ships in six weeks at a defensible pass-rate, produces a renewing customer, and creates the foundation onto which MVP-2 compounds rather than competes.
Bring the smallest-possible test into the next scoping conversation. Two humans. Six weeks. Twenty evals. Eighty percent pass-rate. If the scope cannot defend that bar, cut. The AI MVP Scoping Worksheet at /lead-magnets/ai-mvp-scoping-worksheet walks a founder through the cut against their own idea.
FAQ
Is one AI feature enough to win a paying customer?
In most cases yes. The test is whether the customer would keep paying for it on its own. If the honest answer is no, the feature is wrong-shaped. The Stripe wedge was card payments, not a billing suite. The Calendly wedge was a scheduling link. The narrow wedge is the wedge.
How is this different from generic “narrow your MVP” advice?
Generic narrow-MVP advice was written against deterministic features in 2014. AI features cost differently — eval, observability, fallback, on-call, and vendor risk all scale per feature. The conclusion looks like 2014 advice. The reasoning is stronger.
What if my pitch deck already shows a five-feature suite?
The deck can show a vision; the MVP-1 build is a separate document. Seed investors prefer a credible six-week MVP-1 plan attached to an ambitious vision deck over a deck promising the vision shipped in six weeks. Re-cut the build plan; keep the vision.
How does the smallest-possible test interact with the 6-question PRD?
It produces a defensible answer to question 4 of the idea-to-PRD framework — “what is the one workflow MVP-1 ships?” — and question 5, “what is the eval rubric.” A PRD that fails the test is a five-feature suite pretending to be an MVP-1.
Does this change if I have raised seed funding?
The math is the same. Seed gives a longer runway, not a higher per-feature ceiling. Teams scoping larger MVP-1s because the calendar feels longer ship later and burn runway against scope they should have cut on day one.
What does an AI MVP-1 look like for an agentic product?
Compounding error gets worse with chain length, so narrowness matters more. An agentic MVP-1 should be one task, three to five steps maximum, with the rubric scoring end-to-end success. The 80 percent threshold is harder to clear at chain length 5 than 1. See the AI capability map and the AI feasibility check.
How do I push back when the engineering partner wants to scope bigger?
Ask the partner to walk through the per-feature cost of eval, observability, fallback, on-call, and migration, and to estimate the standing load at the proposed scope. If they cannot, the scope is too large to defend. If they can, the conversation moves from “what features fit” to “what the team can sustain in production” — which is what produces a shippable MVP-1.
What frontier models should MVP-1 target?
Test on the frontier tier the team can afford in production. Currently the high tier is Gemini 2.5 Pro, GPT-5, and Claude Opus 4.8; the cost-sensitive band is Claude Sonnet 4.6; the open-weights hatch is Llama 3.3. Pass the eval rubric on at least two families — single-vendor dependency is itself a scoping mistake.
What if the customer keeps asking for the second feature?
Three options. Ship the first feature properly and use the request as the MVP-2 eval set. Or charge for the second feature as a dated roadmap commitment — revenue against the build rather than scope creep. Or recognise the request as the signal that the first feature is wrong-shaped, in which case the question is pivot, not addition.
Next step
If your MVP-1 is currently a suite, three features, or anything that fails the smallest-possible test, the cheapest correction is on paper, before any code. Run the test. Write the eval. Cut. The AI MVP Scoping Worksheet at /lead-magnets/ai-mvp-scoping-worksheet walks the cut list against your own idea. The first six-week MVP-1 is the one that compounds.
Arthur Wandzel
