Founders arrive at this page with a number in mind — usually “I can ship in 2 weeks with Lovable” or “the vendor quoted 8 weeks for 5 features.” Both numbers are almost always wrong, in opposite directions. The first is a demo masquerading as a product; the second is a feature list masquerading as a scope. The realistic 2026 AI MVP calendar is neither — it is a small set of discrete shapes, each anchored by a real eval contract. This piece names those shapes, the four founder-side drags that stretch any of them, and the cadence that catches drift before week 5.
This piece is the expectations-reset companion to the AI MVP economics playbook, inside the broader idea-to-product manifesto. For the calendar brackets see how long does it take to build an AI MVP; for the price brackets see how much does an AI MVP cost in 2026.
Why the “2 weeks with Lovable” number is wrong
The Lovable, v0, Bolt, and Replit Agent demos are real. A founder pastes a prompt, watches an interface render, clicks through a working flow, and concludes the build calendar collapsed. The conclusion is half-right. The calendar for a demo collapsed. The calendar for an MVP — a product that survives paying users and a frontier-model update cycle — did not.
The gap between a demo and an MVP is four artifacts the demo does not produce:
- An eval set against representative inputs — a sampled set of 30 to 300 inputs with a written rubric (the eval-first build playbook calls this the eval contract). 1 to 3 calendar weeks to build.
- A baseline against that eval set. The first baseline almost always reveals the gap between “looks right on a single input” and “clears the threshold on a sampled set.” Closing the gap is what the build weeks fund.
- An observability layer with named owners. A demo logs to a console. An MVP logs to a trace store with named alert owners, because the first frontier-model update will silently change behavior on a subset of inputs.
- A handoff that survives the founder leaving the room — a runbook, a prompt-versioning convention, and a written escalation path for unanticipated eval failures.
Each is a calendar line, not an engineering line. The Lovable demo collapses the engineering, not the calendar. A founder who treats the demo as the product ships a prototype that hits a failure case in production week 1 — the failure mode behind the ~80% pilot stall rate McKinsey reports across successive State of AI editions and Gartner has corroborated in 2024 and 2025 CIO surveys. The 2-week build is real for demos. It is not real for MVPs.
Why the “8 weeks for 5 features” number is wrong
The opposite failure mode is a vendor proposal with a feature list: “MVP includes inbox triage, meeting summary, lead enrichment, CRM sync, and Slack notifications. 8 weeks. $120K.” It reads defensible because it has a number. It is not defensible because the artifact being priced is the wrong one.
Feature count is not the calendar driver — capability count is. A “feature” is a UI surface; a capability is a thing the model has to do that needs its own eval baseline. Inbox triage, meeting summary, and lead enrichment are three capabilities. CRM sync and Slack notifications are two deterministic integrations. The calendar should be priced against the capabilities, not the bullet count.
Three capabilities is the upper edge of 8 weeks. Each capability needs roughly 1.5 to 3 calendar weeks of eval-baseline-plus-iteration time. Five is a 12-to-14-week build at minimum — or a build that ships three at MVP quality and two as demos.
The integration surface is silent. Two integrations are 1 to 2 calendar weeks each and do not parallelize cleanly with the capability builds. The proposal hides them; they surface in weeks 7 and 8 — when the team should have been hardening, not integrating.
A vendor who quotes “5 features in 8 weeks” is pricing against a 2018 SaaS cost frame and is either inexperienced or planning to cut scope at week 6.
The four calendar archetypes
A 2026 AI MVP calendar belongs in one of four discrete shapes, not a continuous slider. A founder who locates their idea in the right archetype is already halfway to a defensible scope.
Archetype 1 — The 4-to-6-week sprint
A single capability against a single integration, graded by a 15-to-30-input eval, shipped to a small beta cohort. One prompt, one model, one integration. No retrieval, no fine-tune, no agentic tool-use. The right archetype when the founder needs to answer: “is the capability good enough on real inputs to justify a real build?” Examples: meeting-summary against one calendar provider, email triage into 4 labels, structured extraction over one document type.
Archetype 2 — The 6-to-10-week typical build
Two-to-three capabilities, retrieval-augmented backend, two-to-three integrations, a 50-to-100-input eval. Most defensible 2026 builds land here. Most 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. The RAG-for-founders piece walks the retrieval decision.
The 6-week version is the tightly-run one: founder co-authors the PRD, eval suite reuses an existing harness, on-call compressed to 1 week. The 10-week version is the safety-margined one. Both ship the same product; the difference is buffer, not scope.
Archetype 3 — The 10-to-16-week complex build
One of three things, not all three: an agentic feature with tool-use planning; a fine-tuned model where the frontier baseline could not clear the eval; or a multi-feature MVP with cross-feature regression evals. Anthropic’s Building effective agents post walks the agentic shape.
The wrong reason to be here is “we want to be impressive on the demo.” The right reason is that the eval cannot be cleared in a lower archetype.
Archetype 4 — The 12-to-20-week regulated build
A regulated overlay — healthcare, finance, legal — turns a Bracket 2 build into a Bracket 4 build. What changes is the eval suite (which grows a refusal-correctness sub-suite), the security and privacy review (which becomes a multi-week artifact), and the handoff (which includes compliance attestations).
| Archetype | Calendar | Capabilities | Eval inputs | Build path |
|---|---|---|---|---|
| Sprint | 4–6 weeks | 1 | 15–30 | Prompt-only |
| Typical | 6–10 weeks | 2–3 | 50–100 | RAG |
| Complex | 10–16 weeks | 2–3 | 100–300 | Agentic or fine-tune |
| Regulated | 12–20 weeks | 1–3 | 100–500 + refusal | Any + compliance |
The four founder-side drags
Vendor blogs talk about engineering velocity. Almost nothing names the four founder-side drags that quietly stretch any archetype by 1 to 3 weeks each. The founder is half of the build.
Drag 1 — Customer-interview delivery (+1–2 weeks). The PRD week assumes 5 to 8 customer interviews. In practice, two reschedule, one cancels, and the founder is at week 3 with 3 interviews and an incomplete ICP. Fix: book the interviews before signing the contract.
Drag 2 — Stakeholder eval-rubric grading (+1–3 weeks). The eval rubric needs 4 to 8 hours of focused domain-expert grading. Founders rarely block that, so they squeeze it in over 2 to 3 weeks while the build pauses. Fix: pre-book 4 hours every Tuesday morning for the first 4 weeks.
Drag 3 — Internal compliance and security sign-off (+1–4 weeks). Operator-founders inside a 50-to-500-person company route the build through internal IT security and legal review. That review takes 1 to 4 weeks depending on data classification. Fix: start the review at week 0, in parallel with PRD work.
Drag 4 — Decision latency on architecture and scope (+0.5–2 weeks). Mid-build, a question lands: “do we want the agent to escalate after 3 failed tool calls or 5?” The right answer is on a 24-hour clock; answering in 4 days adds 3 days of engineering idle time. Fix: hold a 24-hour decision SLA — block 30 minutes daily for build-question triage.
These four drags add up to 3 to 11 calendar weeks of founder-controllable slip. A founder who pre-handles all four can compress an Archetype 2 build from 10 weeks to 7.
Vendor calendar tells in both directions
A vendor proposal is a calendar artifact before it is a price artifact.
Tells of a too-short calendar
- “3 weeks for an agentic MVP.” Agentic builds do not fit in 3 weeks at MVP quality. The proposal is pricing a demo or shipping a single-prompt feature and calling it agentic.
- “We don’t need an eval suite — our prompts are good.” The vendor will discover the eval cost in week 5.
- “We can compress by parallelizing the build.” Capability builds do not parallelize cleanly; each has its own iteration cycle against its own eval baseline.
- No model-migration buffer. A 10-week build will hit a frontier-model update — Anthropic, OpenAI, and Google ship on multi-week cycles (Artificial Analysis LLM Leaderboard). No buffer pushes the migration cost into production.
Tells of a too-long calendar
- “14 weeks for a single-feature MVP.” Single-feature MVPs fit in Archetype 1 or 2; a 14-week price is inflating scope or hiding bench time.
- “We need 3 weeks of discovery before we can scope.” Three weeks of discovery is a scoping workshop priced as a build phase. The AI scoping workshop article names what 2 days with a senior engineer should produce.
- “We’ve added a buffer for prompt-engineering iteration.” Iteration is the build, not a buffer. A vendor who buffers their own job is junior or padding.
- No fixed milestones. A calendar that does not break into 4 to 6 milestone-bound segments is a time-and-materials engagement priced as fixed-price.
The defensible pattern is a 5-milestone calendar: PRD signed, eval baseline established, build mid-point gate, launch and eval-pass, handoff. Each milestone has a deliverable, a payment trigger, and a kill criterion. The companion piece — stop budgeting AI projects in story points; budget them in eval runs — argues why this milestone shape is the right calendar primitive.
What good cadence looks like
A calendar is half the story; the operating cadence is the other half. Two weekly artifacts catch the drift patterns that cause week-5 surprises.
Weekly demo (30 minutes, every Friday). The engineering team demos the build against the eval set, not against hand-picked inputs. The founder sees the eval-pass rate, representative failure cases, and the iteration plan. The demo is not a status meeting — it is a quality gate against the eval contract. Shape: 5 minutes of eval-pass rate, 15 minutes of 3-to-5 representative failures, 10 minutes of next-week priorities.
Weekly eval review (60 minutes, every Tuesday). Founder, senior engineer, and eval owner review the eval suite itself. New failure modes from production traces get added as new eval cases. The eval suite grows by 10 to 25 percent across the build window — not because the spec changed but because production reveals failure modes the rubric did not anchor. This meeting prevents Drag 2 and Drag 4.
Monthly architecture review (90 minutes). For builds longer than 8 weeks, surfaces build paths that should be reconsidered — a prompt-only build that should switch to RAG, a single-capability build that should add a second. Lets a 12-week build correct course at week 4 instead of week 10.
A vendor who does not run weekly demos against the eval set is delivering on a 2018 SaaS rhythm. A founder who skips the eval review is the single most common cause of week-5 calendar surprise.
The founder self-test
Before signing a contract, answer in writing.
- Which archetype does my idea belong in? Sprint, typical, complex, or regulated. If “I don’t know,” the PRD week has not finished.
- What is the eval set? A representative sample of 15 to 300 inputs, with a written rubric.
- Which of the four founder-side drags am I exposed to? Each unaddressed drag is 1 to 3 weeks of slip.
- Does the vendor’s calendar have 5 milestones with named deliverables? If the calendar is a single number against a feature list, it is a 2018-shape proposal.
- Is there a model-migration buffer? If not, the migration cost lands in production.
- What is the weekly cadence? Weekly demo against the eval set, weekly eval review. “Regular check-ins” is not a designed cadence.
- What is the kill criterion? The eval threshold that, if unmet at the mid-build gate, triggers a scope re-frame rather than a calendar extension.
A founder who can answer all seven is signing against a defensible 2026 AI MVP calendar.
Frequently asked questions
Can a real AI MVP ship in 2 weeks with Lovable?
A demo can. An MVP cannot. The gap is four artifacts the demo does not produce: an eval set, a baseline, an observability layer with named owners, and a handoff. Those take 4 to 16 weeks depending on archetype.
Why does the vendor say 8 weeks when I have 5 features?
Either they are pricing against a 2018 SaaS cost frame or they are planning to cut scope at week 6. Three capabilities is the upper edge of 8 weeks; five is a 12-to-14-week build at minimum.
Which archetype is most common in 2026?
Archetype 2 — the 6-to-10-week typical build. Most useful 2026 AI features need retrieval, 2 to 3 capabilities, and a 50-to-100-input eval. Founders who compress into Archetype 1 ship a demo; founders who default to Archetype 3 over-build.
What happens if the eval suite fails at the mid-build gate?
The build pauses for a 24-to-48-hour diagnosis: is the gap prompt scaffolding (2 to 3 days), retrieval quality (5 to 7 days), or model capability (1 to 2 weeks of fine-tune-or-archetype-change conversation)? A well-built eval catches the failure at week 3 or 4 of an 8-week build.
How much does the founder side actually slip the calendar?
Across the four drags, a founder can silently add 3 to 11 calendar weeks to any archetype. A founder who pre-handles all four can compress an Archetype 2 build from 10 weeks to 7.
Does it matter which frontier model the build targets?
For the calendar, no. The current top-tier models — GPT-5, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 2.5 Pro — are clustered tightly enough on the intelligence index that the calendar is set by the eval suite and the build path, not the model. Switching between SOTA providers is half a day of work and a re-run of the eval baseline.
What about a model update mid-build?
The MVP budget should fund the first model-migration cycle inside the build window. A 10-week build will hit at least one transition; no buffer pushes the cost into production.
Should I expect daily updates from the vendor?
For a sprint, weekly demos plus an async channel are enough. For a 10-to-16-week build, daily 10-minute async updates plus weekly demos and weekly eval reviews is the right rhythm. A vendor who proposes daily live standups is inexperienced or pricing bench time.
What’s the single most common reason an AI MVP timeline slips?
Drag 2 — stakeholder eval-rubric grading. Founders rarely block 4 to 8 hours of focused attention, so the build pauses against an incomplete rubric for 1 to 3 weeks. Pre-book the grading time before week 1.
What’s the right founder posture during the build?
Available within 24 hours for decisions, present at every weekly demo and eval review, on a daily channel for question triage. Not writing code, not reviewing line-by-line implementation. The founder’s job is to grade the rubric and hold the scope.
Where to go next
- AI MVP economics playbook — price each calendar archetype.
- Eval-first build playbook — the eval contract that anchors the calendar.
- Idea-to-product manifesto — the full week-by-week shape of a 2026 engagement.
- Stop budgeting AI projects in story points — the budgeting frame that prevents week-5 surprise.
- The 6-week AI MVP scope milestones — week-by-week deliverables.
Arthur Wandzel
