A signed SOW is not the start of a build — it is the start of a calendar. The next 12 weeks are six phases with six named milestones, and a founder who walks into week one without that map ends up at week five asking the wrong question: how is the build going? The right question is which milestone are we against, and what was I supposed to produce by now? This piece walks the SOW-to-shipped calendar phase by phase, names the milestone for each phase, lists what the founder must produce, and flags the three phases where founders get bottlenecked.
This explainer sits inside the AI MVP economics playbook cluster and under the broader idea-to-product manifesto. For how long the calendar runs, see how long does it take to build an AI MVP; for what fits into 6 weeks, see the 6-week AI MVP scope milestones. The vendor-side view of the opening 14 days is anatomy of an AI agency engagement.
Why the SOW Is the Calendar Anchor
Most timeline posts start the clock at “discovery.” That is the wrong anchor. By the time a founder is asking how long does this take and what happens each week, discovery has already happened. Week 0 is not discovery; week 0 is the day the founder signs.
Anchoring the calendar to the SOW signature does three things. It makes each phase a contract milestone the founder can hold the vendor against. It makes each week’s founder-side deliverable explicit. And it pulls the post-launch on-call period into the contracted calendar rather than leaving it as a vague phase that gets renegotiated under pressure.
A 6-to-12-week AI MVP runs in six phases against that anchor: W0 SOW signed, W1–2 planning and eval baseline, W3–6 build, W7–8 hardening, W9 launch, W10–12 on-call and handoff. Lengths flex by bracket — see the duration brackets piece — but the six-phase structure does not.
The Six-Phase Calendar at a Glance
| Phase | Weeks | Named milestone | Vendor produces | Founder produces |
|---|---|---|---|---|
| 0 | W0 | SOW signed | Kick-off plan | ICP brief, stakeholder list, data-access promise |
| 1 | W1–2 | Eval baseline established | Signed PRD + 50–100-input eval set with rubric | Domain knowledge, failure-case examples |
| 2 | W3–6 | Mid-build gate passed | Eval pass rate 65–80%, integrations wired | Integration credentials, weekly review attendance |
| 3 | W7–8 | Eval threshold cleared | Refusal behavior, guardrails, fallback, inference-cost benchmark | Beta cohort recruited (3–10 users) |
| 4 | W9 | Launched to beta | Production deployment, observability live | Beta intros, feedback channel |
| 5 | W10–12 | Runbook handoff signed | Eval regression suite, runbook, model-migration milestone, retro | On-call ownership, expansion roadmap signed |
Every row has one milestone — not a list of activities. A founder asking the vendor “where are we” against this table gets a binary answer: the milestone is either complete or it is not.
Phase 0 — Week 0: SOW Signed
The day the SOW is signed is week 0. The vendor produces a kick-off plan within 48 hours: named team (senior engineer, eval engineer, project lead), meeting cadence (weekly review, async standup, one milestone review per phase), communication channel, and the dated milestone calendar.
Founder deliverables: an ICP brief in under 500 words, a stakeholder list with named approval authority for PRD scope changes, and a written data-access promise — what corpus the retrieval pipeline will use, where it lives, when credentials arrive. They are the founder saying I know what I am buying in writing.
Milestone: kick-off meeting held, dated calendar countersigned.
The mistake is treating week 0 as a free week. A founder who lets week 0 slide arrives at the week 1 PRD pairing without the ICP brief and burns pairing time defining the user — work that should have been pre-loaded. The vendor calendar slips 2–3 days before week 1 begins.
Phase 1 — Weeks 1–2: Planning, PRD, Eval Baseline
Phase 1 is the most important phase of the entire build. By end of week 2 the engagement either has a defensible PRD and a baselined eval set, or it does not. Everything after week 2 traces back to this artifact.
Week 1 is paired PRD work. The senior engineer and the founder spend 8-to-12 hours together shaping the eval-bound PRD — a 6-to-10-page document naming the capabilities, user surface, integration surface, eval rubric outline, and explicit out-of-scope list. The out-of-scope list matters as much as the in-scope list; it is what the mid-build gate uses to refuse scope creep.
Week 2 is the eval baseline. The eval engineer assembles 50-to-100 representative inputs, drafts a rubric per capability (correct output, acceptable partial, refusal-correct response), and hand-grades a 20-to-30-input warm-up against a baseline prompt. The eval harness is wired into CI by end-of-week.
Founder deliverables: PRD pairing attendance (8-to-12 hours, non-negotiable), domain examples for the eval set, and the first round of failure-case examples — edge cases the vendor would never invent unprompted.
Milestone: signed PRD plus baselined eval set with documented rubric.
This is the first founder bottleneck. A founder traveling, fundraising, or selling during weeks 1–2 converts the PRD into a vendor-only document. The eval set drifts toward generic inputs. By week 4 the build is optimizing against the wrong contract, and weeks 4–6 burn renegotiating it.
Phase 2 — Weeks 3–6: Build Against the Eval
Phase 2 is where most of the engineering happens. But the work is contracted — the vendor is shipping against the eval baseline established in phase 1, not against a moving wish list.
Week 3: first-cut prompts, retrieval pipeline moves from throwaway prototype to production shape, first integration wired in. Eval pass rate is typically 40–60%.
Week 4: second integration wired, prompts refined against failure cases surfaced in week 3, mid-build review at end of week. Pass rate climbs to 55–70%. This is where scope creep tries to enter — the founder sees the build come alive and wants just one more thing. The out-of-scope list signed in week 1 is the founder’s defense against themselves.
Week 5: prompts converge against eval failure clusters, retrieval-quality eval re-run, integration edge cases addressed. Pass rate climbs to 70–80%.
Week 6: the build mid-point gate. The vendor demonstrates the build against the eval suite, the founder sees real outputs, and the gate decision is: continue to hardening, or invoke a scoped change order. A scoped change order at week 6 is a defensible decision; an unscoped one is calendar slippage in disguise.
Founder deliverables: integration credentials by week 3 (the second founder bottleneck), weekly review attendance, decisions returned within 48 hours when the vendor flags a tradeoff.
Milestone: mid-build gate passed with eval pass rate in the 65–80% range, in writing.
Phase 3 — Weeks 7–8: Hardening
Hardening is its own phase, not a bullet inside build. The deliverable shape is distinct: refusal behavior, guardrails, no-AI fallback paths, and inference-cost benchmarking at projected scale.
Refusal behavior: the model should know what it should not answer. A meeting-summary feature should refuse to summarize a meeting with no transcript; an email triage agent should refuse to classify when the context is missing. The eval suite grows a refusal-correctness sub-suite during week 7.
Guardrails: PII redaction, prompt-injection resistance, output schema validation. None are exotic engineering, but each is a 1-to-2-day artifact in its own right.
No-AI fallback: what does the product do when the model is down, the API rate-limits, or the eval gate fails on a specific input? A defensible 2026 product has a graceful degradation path. Without it, the first model outage at week 11 becomes a calendar emergency.
Inference-cost benchmarking: project the build against 10x and 100x launch volume and benchmark per-call cost. A build whose unit economics break at 10x volume is shipping a demo, not a product. The cluster economics anchor walks the cost-line shape.
Founder deliverables: beta cohort recruitment — 3-to-10 named users committed to using the product within a week of launch. This is the third founder bottleneck. The beta is recruited in phase 3, not phase 4.
Milestone: eval threshold cleared (typically 85–95% pass rate against the W2 baseline), refusal sub-suite passing, fallback path tested.
Phase 4 — Week 9: Launch
Launch is one focused week. The vendor deploys to production, observability goes live (per-call traces, eval-set replay against production traffic, cost dashboards), and the first 3-to-5 beta users get private access.
Founder deliverables: warm intros to the beta cohort, a feedback channel (shared Slack channel, feedback form, or scheduled 30-minute calls — the existence matters more than the mechanism), and a written launch announcement to the immediate stakeholder list.
Milestone: production deployment live, dashboards green, first beta users have run their first real workflow. A one-page launch report closes the phase.
Launch is rarely where slippage happens. By week 9 either the build cleared its eval threshold in phase 3 or it did not. A vendor still hardening in week 9 was already behind in week 8.
Phase 5 — Weeks 10–12: On-Call and Handoff
Most timeline posts end at launch. That is the worst mistake on the SERP. Weeks 10–12 are part of the contracted calendar, not a “we’ll figure it out after” period. Three weeks of post-launch on-call separates an MVP that shipped from one that survived its first month.
Week 10: the vendor stays on-call for the beta cohort. Traces and failure cases get logged. The eval suite catches one or two new failure modes added to the regression set. The first model-alias migration milestone often falls here — a 1-to-2 day re-evaluation planned into the calendar.
Week 11: the runbook gets written. How to deploy a prompt change, roll back, add a new failure case to the eval suite, interpret the dashboards. The founder reads it, asks questions, the vendor revises. This is the document the founder owns after handoff.
Week 12: handoff retrospective. The vendor walks the founder through the eval suite, the failure-case backlog, open production tickets, and the expansion roadmap. The founder formally takes on-call ownership. The SOW closes against the runbook.
Founder deliverables: on-call ownership in writing, expansion roadmap signed (or follow-on SOW scoped), retro held with stakeholders.
Milestone: runbook handoff signed.
The Three Phases Where Founders Get Bottlenecked
The vendor calendar is not the whole calendar. Three phases slip because founders did not produce the artifact the SOW assumed they would.
Bottleneck 1 — Weeks 1–2: PRD pairing availability. The founder is the only person who knows what correct looks like in their domain. If they are unavailable during weeks 1–2 — selling, fundraising, or assuming the PRD is the vendor’s job — the eval baseline drifts toward generic inputs and the build optimizes against the wrong contract. Cost: 2-to-3 weeks of renegotiation at week 5. Fix: block 10 hours on the calendar for weeks 1–2 before signing the SOW.
Bottleneck 2 — Week 3: integration credentials. The build assumes API keys, OAuth approvals, or sandbox accounts arrive in week 3. If procurement is involved (common above 50 people), that conversation should have started in week 0. Cost: 1-to-2 weeks of refactor. Fix: file the IT or procurement ticket the day the SOW is signed.
Bottleneck 3 — Weeks 7–8: beta cohort recruitment. Phase 4 launch assumes 3-to-10 beta users with calendars cleared and feedback channels open. Recruiting in week 9 slides launch to week 10 or 11. Cost: 1-to-2 weeks of slippage plus the awkwardness of explaining a slipped launch. Fix: recruit during weeks 6–7, confirm during week 8.
A founder who closes these ahead of their phase buys themselves the tightly-run version of the bracket. A founder who lets them slip pays for the safety-margined version regardless of SOW price.
Frequently Asked Questions
What is the AI MVP timeline from SOW to shipped?
Six phases over 6-to-12 weeks: W0 SOW signed, W1–2 planning and eval baseline, W3–6 build, W7–8 hardening, W9 launch, W10–12 on-call and handoff. Each phase has one named milestone the founder can verify in writing — kick-off plan, signed PRD plus eval baseline, mid-build gate, eval-threshold sign-off, launch report, runbook handoff. The bracket compresses to 6 weeks for a single-capability prompt-only feature and stretches to 12 for the typical 2-to-3 capability retrieval-backed build.
What is week 0 of an AI MVP build?
Week 0 is the day the SOW is signed. The vendor produces a kick-off plan within 48 hours: named team, meeting cadence, communication channel, and a dated calendar mapping onto the six-phase structure. The founder produces an ICP brief, a stakeholder list, and a written data-access promise. The milestone is a kick-off meeting plus a countersigned calendar.
Why is the eval baseline (week 2) the most important milestone?
Because every later phase measures against it. The eval baseline is a 50-to-100-input test set with a written rubric, hand-graded against a baseline prompt, wired into CI. Without it, the build has no way to know whether weeks 3–8 of engineering are making the product better or worse. A build that skips this phase optimizes against a vendor’s gut feel.
How does an SOW-anchored timeline differ from a generic MVP timeline?
A generic MVP timeline starts at “discovery,” collapses eval work into “build,” and ends at “launch.” An SOW-anchored timeline starts at contract signature, names eval baseline as its own phase, treats hardening as distinct from build, and includes the post-launch on-call period as part of the contracted calendar. The result is a calendar both parties can hold each other against, milestone by milestone.
What should I produce as a founder during the build phase?
Integration credentials by week 3, attendance at the weekly review (one hour per week), decisions returned within 48 hours when the vendor flags a tradeoff, and a held line against mid-build scope creep. The most useful thing during weeks 3–6 is not changing scope — the out-of-scope list signed in week 1 is the founder’s defense against themselves.
What happens if the eval pass rate stalls at week 6?
The build pauses for diagnosis. The mid-build gate exists for this. Three possible answers: prompt scaffolding is wrong (2-to-3 days to fix), retrieval quality is the bottleneck (5-to-7 days), or the bracket itself is wrong (a 1-to-2 week scoped change order). A well-built eval surfaces this at week 4, not week 6.
Why is hardening a separate phase and not part of build?
The deliverable shape is different. Build produces capabilities measured by eval pass rate. Hardening produces refusal behavior, guardrails, no-AI fallback, and inference-cost benchmarks measured by separate sub-suites. Collapsing the two loses the discipline of treating safety and unit economics as contracted milestones. A demo can skip hardening; a product cannot.
How long is the post-launch on-call phase?
Two to four weeks. Week 10 is observation against the beta cohort, week 11 is runbook authoring, week 12 is the handoff retro. A compressed bracket runs it in 2 weeks; a regulated build runs it in 4. Cutting it to zero is the most common contracting mistake — the build ships, the founder takes on-call with no runbook, and the first failure case at week 13 becomes an emergency.
Should the on-call period be in the original SOW?
Yes. A 2-to-4 week on-call window with named milestones (runbook, regression suite, retro) belongs inside the original contract. Negotiating it after launch — when the build is live and the founder is in a weak negotiating position — almost always results in a more expensive follow-on SOW or an undocumented handoff.
Closing
A signed SOW is not the start of a build — it is the start of a six-phase calendar with six named milestones. A founder who treats the SOW as the calendar anchor walks into each phase knowing what the vendor owes, what they themselves owe, and what complete looks like in writing. A founder who treats the SOW as a payment trigger walks into each phase asking the vendor how is it going? — the worst question to ask, because the only honest answer is compared to what? For the dollar-cost view of each phase, read the AI MVP economics playbook; for the broader framing, read the idea-to-product manifesto.
Arthur Wandzel
