A 2026 AI MVP ships in 4 to 16 weeks, and the bracket the build lands in is set in the first two weeks. The 4-to-6-week sprint, the 6-to-10-week typical build, and the 10-to-16-week complex build are not stretchy versions of each other — they are three different shapes of engagement that ship three different scopes of product. Founders who treat the calendar as a single sliding number end up at week 5 with a feature that compiles and a product that does not work. The right question is not how fast the build runs. It is which bracket the scope belongs in.
This explainer is the companion to the AI MVP economics playbook, which prices each cost line the calendar generates, inside the broader idea-to-product manifesto. For dollar cost see how much does it cost to turn an AI idea into a shipped MVP; for what 6 weeks ships see the 6-week AI MVP scope milestones.
The Three Calendar Brackets
There are three brackets, not five and not two. The distinction between them is the shape of the eval contract and the build path, not the founder’s tolerance for risk. A founder who picks the wrong bracket loses 3-to-5 weeks discovering it.
Bracket 1 — The 4–6 Week Sprint
A 4-to-6-week AI MVP is a single-capability, prompt-only feature against a single integration, graded by a 15-to-30-input human eval, shipped to a known beta cohort. That is the entire envelope. Examples that fit cleanly: a meeting-summary feature pulling from one calendar provider, a customer-email triage agent classifying into four labels, a structured-extraction feature over a single document type.
The shape is: week 1 paired PRD work between founder and senior engineer, week 2 eval baseline and prompt scaffolding, weeks 3-4 build and iteration against the eval, weeks 5-6 launch and hardening if needed. No retrieval, no fine-tune, no second feature, no agentic tool-use. One prompt, one model, one integration.
Founders compress to 4 weeks when they co-author the PRD themselves and the eval set is 15 inputs rather than 30. They stretch to 6 weeks when an integration is messier than expected. Below 4 weeks, the build is not an MVP — it is a demo whose first production user will find a failure case the engineer never tested.
Bracket 2 — The 6–10 Week Typical Build
A 6-to-10-week AI MVP is a 2-to-3-capability feature with a retrieval-augmented backend, two or three integrations, and a 50-to-100-input eval. This is where most defensible 2026 builds land. The shape is recognizable: week 1 intake and ICP, weeks 2-3 eval-bound PRD plus a thin retrieval prototype, weeks 4-7 build against the eval, weeks 8-9 launch and the first model-migration buffer, week 10 handoff.
Most genuinely useful AI features need retrieval. A meeting-summary feature without grounding hallucinates names; an email triage feature without per-account context routes the high-value lead to the wrong queue. Retrieval adds 1-to-2 weeks; a broader eval suite adds another 1-to-2; the integration surface adds another 1-to-2.
A 6-week build inside this bracket is the tightly-run version. A 10-week build is the safety-margined version. Both ship the same scope of product.
Bracket 3 — The 10–16 Week Complex Build
A 10-to-16-week AI MVP is one of three things: an agentic feature with tool-use planning, a fine-tuned-model feature where a base model could not clear the eval threshold, or a multi-feature MVP with cross-feature evals. Each adds genuine scope, not just risk.
The agentic shape adds 2-to-4 weeks for the tool registry, planning loop, and agent-level evals (which grade trajectory and refusal behavior, not just final output). The fine-tune shape adds 2-to-4 weeks for dataset assembly, training, and benchmarking against the frontier baseline. The multi-feature shape adds 2-to-4 weeks because the eval suite covers handoffs between features.
The wrong reason to be in this bracket is “we want to be impressive on the demo.” The right reason is that the eval cannot be cleared in a lower bracket — the agentic vs static prompt decision article walks the deeper test.
The Five Factors That Lengthen a Build
There are exactly five factors that meaningfully extend an AI MVP calendar.
1. Eval scope creep (+1–3 weeks). The eval set grows mid-build because a stakeholder finds a failure case nobody anchored in the original rubric. A 30-input eval suddenly needs to be a 60-input eval. This is the single most common calendar extender. The piece on budgeting in eval runs argues why story-point budgeting masks this exact dynamic.
2. A second feature added late (+2–4 weeks). The founder gets to week 4 and realizes the first feature alone is not a product. A second capability is added, often as “just one more prompt.” But the second capability requires its own eval baseline, its own iteration cycle, and a cross-feature regression suite.
3. Retrieval introduced after the build started (+1–2 weeks). The PRD said “prompt-only” and the first eval reveals hallucination on the long tail. Retrieval gets added in week 4: a corpus to ingest, a chunking strategy to test, a retrieval-quality eval to baseline, and a re-run of the original eval set. The eval-first build playbook argues retrieval should be scoped at PRD time, not discovered at week 4.
4. A fine-tune cycle (+2–4 weeks). A frontier-model prompt cannot clear the eval, and a fine-tune of a smaller model becomes the answer. Add 2-to-4 weeks for dataset, training, evaluation against the frontier baseline, and hosting. Fine-tuning is rarely the right MVP call.
5. Agentic tool-use design (+2–4 weeks). What starts as a single prompt becomes a prompt-plus-tool-registry-plus-planning-loop. The agentic surface adds work in three places: tool definitions, planning prompt, and agent-level evals.
A build that hits two of these factors lands in Bracket 3 even if it started in Bracket 2. The honest reading is to anticipate one — eval scope creep being the most likely — and bake the buffer in.
The Three Factors That Do Not
These three generate the most calendar-related noise in founder-vendor conversations and have near-zero impact on ship date.
Model choice changes inside the SOTA tier. Switching the build target from GPT-5 to Claude Opus 4.8 to Gemini 2.5 Pro is a half-day’s work for an experienced engineer, not a calendar event. The Artificial Analysis leaderboard shows the top three are clustered tightly enough that the eval will pass or fail on prompt scaffolding, not on which provider is underneath.
Prompt iteration count. Whether the build runs 30 prompt iterations or 90 to clear the eval is not a calendar driver. Each iteration is minutes-to-hours of engineering time. The calendar driver is whether the eval is well-anchored — a well-built eval converges in 1-to-2 weeks regardless of iteration count.
Cosmetic UI work. Whether the demo screen is in Tailwind defaults or a polished design system is independent of the AI calendar. UI polish is a parallel work stream — a clean demo takes 2-to-3 days, a polished one takes 1-to-2 weeks. Neither extends the AI build calendar.
These three are not insignificant in the product. They are insignificant in the calendar, and founders who anchor their ship-date anxiety on them are looking in the wrong place.
The Model-Migration Buffer
Frontier-model providers ship behavior-changing updates on cycles of weeks. Anthropic released multiple Claude Opus and Sonnet variants over the past year; OpenAI shipped successor updates inside the GPT-5 family; Google shipped Gemini 2.5 and 3.x family models in tight succession. A 10-week build has a meaningful probability of crossing one such update.
The cost in calendar terms is a 1-to-2-day re-evaluation cycle. The eval suite gets re-run against the new alias, prompt scaffolding gets minor adjustments if behavior diverges, and the on-call buffer absorbs the day. A build that did not fund this buffer instead loses 4-to-7 days scrambling.
Best practice in 2026 is to pin to a dated model alias for the duration of the build, plan one explicit re-evaluation milestone, and design the prompt scaffolding so a model swap is a half-day exercise rather than a multi-week refactor.
An 8-Week AI MVP, Week by Week
A typical Bracket 2 build is a 2-capability, RAG-backed feature with two integrations and a 60-input eval, shipping to a beta cohort of 15-30 users.
Week 1 — Intake and PRD. Founder and senior engineer pair on the ICP brief, the eval contract sketch, and the architecture decision record. By end-of-week, both have signed a 6-to-10-page eval-bound PRD. No code is written this week.
Week 2 — Eval baseline and retrieval prototype. The engineer assembles a 60-input test set, drafts the rubric for each capability, and hand-grades 20-to-30 baseline outputs. A throwaway retrieval prototype tests whether the chunking strategy will work. The eval harness is wired into CI by end-of-week.
Week 3 — Build phase 1. First-cut prompts written, retrieval pipeline moves from throwaway to production-shape, first integration wired in. Eval pass rate is typically 40-60% — above random, below ready.
Week 4 — Build phase 2. Second integration wired, prompts refined against failure cases, mid-build review. Pass rate climbs to 65-75%. This is where eval scope creep usually tries to enter — the milestone gate exists to refuse it.
Week 5 — Hardening. Prompts converge against the eval threshold, edge-case handling added (refusal behavior, guardrails, the no-AI fallback), inference-cost curve benchmarked at projected scale. Pass rate climbs to 80-90%.
Week 6 — Launch readiness. Build clears its eval threshold, the model-migration re-evaluation milestone runs, the front-end demo UI is finalized. First 3-5 beta users get private access.
Week 7 — Beta and observe. The beta cohort uses the product against real workflows, traces and failure cases are logged, the eval suite catches one or two new failure modes that get added to the regression set.
Week 8 — Handoff and runbook. The runbook is written, the handoff document finalized, and the founder takes ownership of on-call. The MVP ships, the eval baseline is documented.
A founder should be able to ask their vendor “where is the week-2 eval baseline” and “what is the week-6 model-migration milestone.” A vendor who cannot answer is selling against a 2018-style web MVP shape.
Founder-Side Bottlenecks
The vendor calendar is not the whole calendar. Founder-side bottlenecks routinely add 1-to-3 weeks.
Data and corpus access. If the retrieval pipeline needs a domain corpus and the founder cannot produce it in week 1, the build starves. Common pattern: the founder agrees to “send the documents” and three weeks later sends them.
Integration credentials. API keys, OAuth approvals, sandbox accounts. The second integration assumes credentials in hand by week 4. If procurement is involved (common in enterprise), start that conversation in week 0.
Customer access for the beta. Week 7 assumes 3-to-5 beta users lined up. Recruit during weeks 4-5, not after launch.
Founder availability for the PRD pairing. Week 1 is paired work. A founder unavailable that week — selling, fundraising, traveling — converts the PRD into a one-sided document and pushes the bracket up by 1-to-2 weeks.
Frequently Asked Questions
How long does it actually take to build an AI MVP in 2026?
Four to sixteen weeks, with the bracket set by the eval contract and the build path. A prompt-only single-capability MVP ships in 4-6 weeks. A 2-3 capability MVP with retrieval (the typical 2026 shape) ships in 6-10 weeks. An agentic, fine-tune-bearing, or multi-feature MVP ships in 10-16 weeks. The bracket is set by the scope in week 1.
Can an AI MVP be built in under 4 weeks?
A demo can. An MVP — meaning a product with a defensible eval baseline that a beta cohort can use against real workflows — almost never can. Below 4 weeks, there is not enough calendar to baseline an eval set, run prompt iteration against it, and harden the build for first-user contact. What ships at 3 weeks is a prototype that will hit a failure case the engineer never tested in week 1 of production.
Why do AI MVPs take longer than SaaS MVPs?
Three structural reasons. The eval contract is a 1-to-3-week artifact with no SaaS equivalent. The retrieval, fine-tune, and agentic build paths are different shapes of engineering, where SaaS architecture is largely commoditized. The model-migration buffer has no SaaS equivalent. Together, these add 3-to-6 calendar weeks.
What’s the difference between a 6-week and a 10-week build of the same feature?
The difference is buffer, hardening depth, and on-call structure — not more features. The 6-week build is the tightly-run version: the founder co-authors the PRD, the eval suite reuses an existing harness, the on-call period is compressed. The 10-week build is the safety-margined version: each step has buffer, the eval suite is built from scratch, the founder is not on-call themselves. The deeper sibling treatment is the 6-week AI MVP scope milestones piece.
Does the choice between GPT-5, Claude Opus 4.8, and Gemini 2.5 Pro change the calendar?
No. The current top-tier frontier models are clustered tightly enough on the intelligence index that the build calendar is set by the eval suite and the build path, not the model. Switching the build target between SOTA providers is a half-day of work and a re-run of the eval baseline. Founders who spend weeks debating model choice are slowing their own decision-making, not their build.
Should I expect a vendor to commit to a fixed calendar?
Yes — to a fixed calendar against a fixed scope, with a milestone-based payment structure. The defensible 2026 pattern is a 5-milestone calendar: PRD signed, eval baseline established, build mid-point gate, launch and eval-pass, and handoff. A vendor who cannot map their proposal onto this shape is pricing against a 2018 SaaS cost frame. The AI feature pilot vs full MVP comparison walks the cost-and-calendar tradeoff between the pilot bracket and the full MVP bracket.
What happens if the eval suite fails at week 5?
The build pauses and the team diagnoses whether the gap is prompt scaffolding (2-3 days to fix), retrieval quality (5-7 days), or model capability (1-2 week conversation about fine-tune or bracket change). A well-built eval catches the failure at week 3 or 4, not week 5 — which is why week 2 is the eval-baseline week.
Can the calendar be compressed by hiring more engineers?
Almost never. The bottleneck is sequential — eval baseline must be set before build, build must harden before launch, launch must observe before iteration. The right way to compress is to narrow scope, not to add headcount.
How do regulated industries (healthcare, finance, legal) change the calendar?
Add 2-to-4 weeks. The eval suite has to grow a refusal-correctness sub-suite, the security and privacy review becomes a multi-week artifact rather than a checklist, and the handoff has to include compliance attestations. A regulated-industry MVP that targets the unregulated Bracket 2 calendar is signing against a misframed scope.
Closing
A 2026 AI MVP ships in 4 to 16 weeks, and the bracket is set in week 1, not negotiated in week 5. The calendar is downstream of the eval contract — a founder who sets the eval contract first owns the calendar; a founder who lets the vendor set the calendar first ends up renegotiating it at week 5. Read the AI MVP economics playbook next for the dollar-cost line items that map onto each week, or the idea-to-product manifesto for the broader framing.
Arthur Wandzel
