An idea-to-product engagement is twelve weeks long, and every week has a named output, a founder time-cost in hours, and a one-line test for whether the week was on track. Most founders sign a Statement of Work that names the total duration and the total fee, then discover by Week 4 that they cannot picture the chronology — what they must show up for, what is allowed to slip. This article is that chronology, written for a non-technical founder.
This walkthrough builds on the founder-AI-partner operating manual within the idea-to-product manifesto. Companion reading: discovery call vs paid pilot, inside the SFAI Labs operating cadence, and the first 14 days of an AI agency engagement.
Why a 12-week shape, not 6 and not 26
A six-week engagement ends before the eval threshold can be defended. A six-month engagement is a team build wearing the costume of an MVP. Twelve weeks is the shortest interval that fits five things: a written PRD, a versioned eval set, a working prototype, a hardened prod release, and a two-week on-call window. Cut any one of these and the artifact loses defensibility.
McKinsey’s The state of AI in 2025 reports 78% of organisations now use AI in at least one business function — the procurement pressure is real. A 12-week shape gives a founder a defensible chronology and constrains scope creep mechanically.
The 12-week calendar at a glance
| Week | Named output | Founder hours | One-line success criterion |
|---|---|---|---|
| W1 | Kickoff memo + data access matrix | 3 | Every data source the build needs is either accessible or has a named blocker. |
| W2 | PRD v1 + versioned eval set (50–100 items) | 3 | The eval set, when run against a baseline model, scores below the launch threshold. |
| W3 | Prototype v1 (end-to-end, ugly) | 1 | A clickable artifact exists that runs the happy path. |
| W4 | Prototype v2 (10 hardest eval items) | 2 | The 10 hardest eval items have at least a stubbed approach. |
| W5 | Eval baseline run + gap report | 3 | The team can name the 3 biggest quality gaps and the rewrite plan. |
| W6 | Hardened build (eval ≥ launch threshold) | 1 | The full eval set passes the agreed threshold (e.g., 80% pass rate). |
| W7 | Integration v1 (auth, billing, logs) | 1 | The system can be used by a user who is not the partner team. |
| W8 | Integration v2 (one external system) | 2 | At least one external integration (CRM, email, payments) is live in staging. |
| W9 | Launch-readiness review | 3 | The launch checklist (security, observability, runbooks) is fully green. |
| W10 | Production launch | 3 | The system is live for at least 10 real users and the eval set still passes. |
| W11 | On-call + first patch | 1 | Every production incident has a written post-mortem within 48 hours. |
| W12 | Handoff + 90-day roadmap | 2 | The founder can answer “what changes next month” from a written doc. |
Twelve weeks. About 25 hours of founder time total — clustered into five show-up days, with the rest asynchronous Loom and PR reviews.
W1 — Kickoff and data access
Named output: kickoff memo (3–5 pages) plus a data-access matrix. Founder time: 3 hours.
A 2–3 person partner team produces three artifacts: a kickoff memo restating the product in the partner’s own words (if they cannot do this in under 500 words, the misalignment is already visible); a data-access matrix with every source labelled green, yellow (5-day acquire), or red (legal/vendor escalation); and a risk register naming three derailment risks.
Success criterion: every data source classified, no yellow sources open by Friday of W1. The common failure is a yellow source that quietly turns red by W3.
W2 — PRD and the eval set
Named output: PRD v1 (5–10 pages) and a versioned eval set of 50–100 items. Founder time: 3 hours (PRD review, eval-set review, async PR comments).
The eval set is the most under-explained artifact in AI MVP work — 50–100 concrete inputs paired with expected outputs and a graded pass/fail rubric. Stack Overflow’s 2025 Developer Survey found 84% of developers use or plan to use AI tools, and “lack of evaluation rigor” is the top reason AI features quietly degrade. Without an eval set, “the model got worse” is a vibe; with it, “the model dropped 7 points on the customer-onboarding subset” is a defensible number.
Success criterion: when run against a baseline model with no special prompting, the eval set scores below the launch threshold (e.g., baseline 45% vs target 80%). If baseline already passes, the build is unnecessary.
W3–W4 — Prototype
Named output: a clickable end-to-end prototype on the happy path (W3); a second iteration handling the 10 hardest eval items (W4). Founder time: 1 hour W3 (async Loom), 2 hours W4 (Loom plus walkthrough).
W3 is a quiet week. The founder steps back. Injecting scope here (“what if it also did X?”) is the leading cause of timeline slips. The prototype should be ugly: one happy-path flow, a stubbed UI, an unstyled output. W3 exists to flush integration risks (the API does not return what the docs promised, model latency is 4× the budget) before hardening begins.
W4 narrows to the 10 hardest eval items — usually the edge cases the founder spotted in W2’s PRD review. By Friday of W4 the partner should demo each on a Loom with a one-sentence theory for each that does not yet work.
Success criterion: the happy path runs (W3); a stubbed-but-named approach exists for each of the 10 hardest items (W4). Quality evaluation is the W5 milestone, not now.
W5–W6 — Eval-pass and harden
Named output: baseline eval run + gap report (W5); hardened build passing the threshold (W6). Founder time: 3 hours W5 (show-up day — eval-review meeting), 1 hour W6 (async report review).
W5 is the most diagnostic week of the entire engagement. The partner runs the full eval set against the W4 prototype, produces a gap report naming the 3 biggest quality gaps, and proposes the rewrite plan. A 90-minute eval-review walks the founder through the worst-failing items. Anthropic’s published case studies show the largest quality lift comes from this discipline — looking at failures, not averages.
W6 hardens: rewrite prompts, swap models if needed, add guardrails, re-run the eval set until it passes. By Friday of W6 the build must score at or above the threshold (commonly 80%, contract-specific).
W5: 3 named gaps with a written fix plan. W6: eval set passes the threshold on at least two consecutive runs.
W7–W8 — Integration
Named output: build wired into auth, billing, observability (W7); connected to one external system (W8). Founder time: 1 hour W7 (quiet week, async), 2 hours W8 (one integration call).
W7 is the second quiet week. The partner stitches in the infrastructure real users require: auth, billing or usage metering, structured logs and dashboards. None of this changes model behaviour, so the founder steps back.
W8 connects to one external system — typically a CRM (Salesforce, HubSpot), a transactional email provider (Postmark, Resend), or a payments rail (Stripe). One integration. Not three. Partners who try to ship three integrations in W8 are the partners who arrive at W10 with no launch.
Success criterion: a non-partner user can log in and see structured logs (W7); one external system is live in staging by Friday of W8.
W9 — Launch prep
Named output: launch-readiness review with a green checklist across security, observability, runbooks, rollback. Founder time: 3 hours — a show-up day (checklist walkthrough + rollback review).
The checklist has ~30 items in four buckets: security (secrets, dependency scan, PII), observability (alerts, dashboards, on-call), runbooks (incident response, model-failure protocol), and rollback (revert in under 15 minutes). Every item is green or has a named owner with a fix date inside W9.
The most common W9 failure is production environment access — the founder has not given deploy credentials, or the cloud account has policy controls the partner has not seen. Resolve by Wednesday of W9 or W10 slips.
Success criterion: every item green; rollback tested end-to-end at least once.
W10 — Launch
Named output: live in production for at least 10 real users; the eval set still passes against production traffic.
Founder time: 3 hours — a show-up day. On the launch call, review the first hour of real-user behaviour, sign off.
The launch itself takes 30–60 minutes. The rest of W10 is observation. The point is not “ship” — the build has been shippable since W6. The point is evidence under load: the eval set passes when real users (not partner-team test cases) hit the system.
Success criterion: ≥10 real users have used the system end-to-end; the eval set passes against the first week of production traffic.
W11–W12 — On-call and handoff
Named output: written post-mortem for every W11 incident; handoff document + 90-day roadmap (W12). Founder time: 1 hour W11 (async), 2 hours W12 (handoff walkthrough + roadmap review).
W11 is the third quiet week. The partner runs the on-call rotation, the founder watches from outside, and any production incident is met with a written post-mortem inside 48 hours. The post-mortem is evidence that the partner can operate the system, not just build it.
W12 is the handoff. The partner produces a handoff document naming the architecture, the deploy process, the model-update procedure, the eval-rerun cadence, the on-call escalation path, and a 90-day roadmap. By Friday of W12 the founder should be able to answer “what changes next month?” from a single written document.
Success criterion W11: every incident has a 48-hour post-mortem. W12: the founder can run a 10-minute external briefing from the handoff doc alone.
Founder show-up days and quiet weeks
Founder time clusters into five show-up days where attendance is non-substitutable: W1 kickoff, W2 PRD review, W5 eval review, W9 launch-readiness, W10 launch. Everything else is asynchronous. Founders who attend every standup burn out by W6; founders who attend zero meetings lose the diagnostic feel.
The corresponding quiet weeks are W3, W7, and W11 — partner does deep work, founder steps back. Naming the quiet weeks in the SOW protects both sides.
How an engagement slips, and the three weeks to watch
Three weeks where 12-week engagements most often slip:
- W2 — data access. A yellow source from W1 quietly slips to red. Fix: enforce the Friday-of-W1 zero-yellow rule.
- W5 — eval threshold. The eval set is harder than expected, or the model choice is wrong. Fix: surface the gap in the W5 review, not at the W6 hardening deadline.
- W9 — production environment access. The partner cannot deploy to prod because of a credential or policy issue. Fix: require staging-to-prod parity by Friday of W8.
Watch those three weeks more closely than the rest, and the calendar holds.
FAQ
How much founder time is required across the full 12 weeks?
About 25 hours, clustered into 5 show-up days (W1, W2, W5, W9, W10) of 3 hours each plus ~10 asynchronous review hours across the other 7 weeks. Founders who plan “1 hour a week” underestimate the show-up days; founders who plan “10 hours a week” burn out by W6.
What if my engagement is 6 weeks instead of 12?
A 6-week engagement is feasible only if the eval set is small (under 30 items), data access is fully green at W1, and there is no external-system integration. Most 6-week SOWs are 12-week engagements with the eval-rigor, integration, and on-call phases cut — which means the founder absorbs those risks after launch.
What happens if the W5 eval review fails?
The 12-week shape extends by 1–2 weeks and the SOW’s change-order clause is invoked. If the partner cannot articulate a credible gap-closure plan in the W5 meeting, that signal matters more than the eval score itself — it means the team does not yet understand the failure modes well enough to fix them in W6.
What does the founder not do during a 12-week engagement?
The founder does not write code, design the architecture, pick the model, run evals, or commit to deadlines on behalf of the team. The founder owns three things: the product vision, the data-access unblocking, and the W10 launch sign-off.
Can I run two partner teams in parallel on the same build?
Almost never. Parallel engagements split founder attention, fragment the eval set, and triple coordination cost without tripling output. Run discovery calls in parallel before the SOW; run one partner for the build.
What is not on the 12-week calendar?
Brand identity, marketing site, growth experiments, sales onboarding, support tooling, fundraising. These are the founder’s parallel work. A partner who folds them into the SOW is mispricing.
How do I tell if Week 4 is on track without being a developer?
Ask three questions on the Friday W4 Loom: (1) “Show me each of the 10 hardest eval items being attempted.” (2) “Which 3 will be hardest to fix?” (3) “What is the plan to fix them by W6?” If the team answers all three in plain language, W4 is on track.
What deliverables should I demand at handoff in W12?
Five artifacts: production codebase with a deploy README; versioned eval set with a rerun procedure; architecture decision record; on-call runbook; 90-day roadmap. If any is missing, the handoff is incomplete.
Is 12 weeks the industry standard?
Twelve weeks is the median for a senior-led AI MVP build in 2026. 18-to-24-week SOWs usually buy team scale-up; 4-to-6-week SOWs usually buy a prototype, not a production system.
For the weekly cadence as a one-page printable PDF plus monthly editorial on the idea-to-product engagement model, subscribe to the SFAI Labs newsletter. One email a month, written for non-technical founders about to sign their first AI development SOW.
Arthur Wandzel
