A defensible idea-to-product SOW contains 9 load-bearing sections — and the founders who counter-sign an SOW missing any of them pay 30%+ overruns to repair the gap. This page is the procurement-stage anatomy: nine sections, what good language looks like, what red-flag language looks like, four annotated example fragments, and a 5-question checklist to run before counter-signing. It assumes you have a proposal in front of you and counsel asking whether to sign.
The Statement of Work is the contract that turns the idea-to-product service category into an enforceable engagement. Most SOWs we review for founders are inherited from pre-AI software-development templates — they handle scope and timeline well, and handle eval acceptance, model-vendor pass-through, and change orders badly. The 30%+ overrun number is not a market accident. It is a predictable consequence of the document.
The 9 sections of a defensible SOW
Every defensible idea-to-product SOW we have seen reduce overrun risk in 2026 contains the same nine load-bearing sections. Five translate cleanly from traditional software SOWs. Four are AI-specific and tend to be missing or wrong in inherited templates.
| # | Section | AI-specific? | Common failure mode |
|---|---|---|---|
| 1 | Scope | No | Aspirational, not bounded |
| 2 | Milestones and timeline | No | Calendar-driven, not deliverable-driven |
| 3 | Deliverables | No | Marketing language, not acceptance-grade detail |
| 4 | Pricing structure | No | T&M dressed up as fixed-fee |
| 5 | IP and ownership | Partially | Code is covered; prompts and eval sets are silent |
| 6 | Eval acceptance criteria | Yes | Missing entirely; eval treated as internal QA |
| 7 | Change-order policy | Partially | ”Any change requires written approval” — too vague |
| 8 | Termination clause | No | Termination-on-notice without milestone-boundary language |
| 9 | Post-launch on-call | Yes | Vague “we’ll help” with no numeric SLA |
The 9 sections, one by one
Section 1: Scope
A fence around what the partner commits to build before the engagement starts — not a description of the product.
Good: names one product, one persona, one task, one primary frontier-vendor model. Inclusions stated as noun phrases. Exclusions stated explicitly (“native mobile, enterprise SSO, SOC 2 audit start”). Binds itself by reference to a written eval-first PRD.
Red flag: aspirational phrasing (“a market-leading AI product”), open-ended catch-alls (“plus any additional features identified during the engagement”), scope-by-category. A scope statement that does not name what is excluded is a wish list, not a fence.
Section 2: Milestones and timeline
A schedule of named milestones with deliverables and acceptance criteria for each.
Good: four milestones — M1 (PRD and eval set, week 2), M2 (MVP-1 deployed with paying users, week 6), M3 (hardening, week 10), M4 (handoff and 30-day on-call, week 12). Each has a one-line headline deliverable and a one-line acceptance criterion. Calendar dates are week numbers from a defined kickoff.
Red flag: “Phase 1, 2, 3” without acceptance criteria. Calendar dates with no tie to deliverables. Milestones that describe partner activity (“design phase”) instead of founder-visible artifacts.
Section 3: Deliverables
An itemized, acceptance-grade list of what the founder receives at each milestone.
Good: each deliverable named with enough specificity that a third party could grade whether it was produced — “PRD (15–25 pages, eval-first format)” rather than “product documentation.” Each owned by a single party at handoff.
Red flag: deliverables in adjectives instead of artifacts (“a comprehensive PRD”). Ownership at handoff unstated. Deliverables that exist only in the partner’s project-management tool.
Section 4: Pricing structure
The change-order containment device — milestone-billed fixed fees compress the partner’s optionality to scope-creep.
Good: milestone-billed fixed fees, payment on acceptance. Typical 2026 shape: 20% at signing, 30% at M1, 30% at M2, 15% at M3, 5% at M4. Reimbursables capped at 5–10% of total. Frontier-model inference costs explicitly excluded — the founder owns the model contract from M2 onward.
Red flag: T&M dressed as fixed-fee (“$150K estimated, billed weekly against actual hours”). Payment front-loaded (“60% at signing”). Model-inference costs billed through the partner with a markup — this destroys cost portability at handoff. See the AI MVP economics playbook for the underlying decomposition.
Section 5: IP and ownership
Traditional SOWs handle application code well and are silent on prompts, eval sets, and model-vendor contracts. The AI-MVP SOW must close those gaps.
Good: application code assigned to the founder at M4. Prompts shipped as a versioned library in the founder’s repo. Eval set and rubric owned by the founder with grader notes transferred. Runbook, customer relationships, and data owned by the founder. Frontier-model contracts on the founder’s billing from M2 onward.
Red flag: IP-assignment covering “the code” but silent on prompts or eval sets. A “partner-retained prompt library” — the most common predatory clause in 2026 AI MVP SOWs, because it turns the founder into a permanent licensee of their own product’s brain. Model contracts billed through the partner with no portability clause.
The eval set is what lets the product survive a frontier-model upgrade. A founder who owns it can swap from Claude Opus 4.8 to a later release in an afternoon. A founder who does not pays the partner to repeat validation.
Section 6: Eval acceptance criteria
A binding, gradable standard for whether the partner has delivered each milestone’s AI output at quality. The section most absent from inherited templates.
Good: M1 acceptance — eval set constructed (30–80 cases), two-grader agreement above 80%, capability probe scoring 7/10+ on the named model. M2 acceptance — production deployment passes the M1 eval set at the agreed threshold (typically 80–90% at “good” or “excellent”), cost-per-query within budget, first paying user completes the core task end-to-end without engineer-in-the-loop assistance. M3 acceptance — eval suite wired into CI as a regression gate, seven days of unattended uptime, cost-per-query holding under realistic concurrency.
Red flag: “Acceptance upon founder sign-off” — collapses the gate into a subjective negotiation. “Acceptance upon successful demonstration” — demos are stage-managed; eval suites are not. No mention of eval at all — the single best predictor of a 30%+ overrun.
If the SOW does not name the eval set as a contractual acceptance gate, the founder is buying a demo, not a product.
Section 7: Change-order policy
A bounded, procedural rule for how scope changes get priced, approved, and folded in. The most effective tool against the absorbed-favor trap — small “while you’re in there” requests that compound into 30%+ overruns. See the AI agency change-order playbook for the operating procedure this clause encodes.
Good: a five-step procedure — (1) trigger in writing, (2) sizing within 3 business days, (3) pricing as fixed add-on or defined cut elsewhere, (4) written approval before any partner work begins, (5) logging as a numbered amendment. Names the absorbed-favor trap explicitly and refuses it.
Red flag: “Any change requires mutual written approval.” Vague, no procedure, no sizing rule. “Minor changes may be absorbed at the partner’s discretion” — the absorbed-favor clause that creates 30%+ overruns. No defined sizing window — the partner can stall a change request indefinitely.
Section 8: Termination clause
Defined exit points and the deliverable state at each one — makes the engagement reversible.
Good: termination at clean milestone boundaries — M1, M2, M3 each a defined exit point with transfer of work-to-date in deliverable-grade form. Mutual termination-for-convenience with 14 days’ notice and prorated payment. Termination-for-cause defined narrowly (material breach uncured for 14 days, insolvency, IP infringement).
Red flag: termination-for-convenience by the partner with no requirement to transfer work-to-date. Penalty clauses for founder-initiated termination exceeding earned fees plus reasonable wind-down costs. Any clause that retains partner ownership of work-to-date upon termination — the founder paid for it, the founder owns it.
Section 9: Post-launch on-call
A bounded, numeric SLA for the period after M4 handoff. What makes the engagement actually ownable by a non-engineer founder.
Good: a 30-day on-call period from M4 acceptance. A first-response SLA — typically 4 business hours to first response, 1 business day to resolution-or-workaround for severity-1 incidents. An incident cap (5–10 in the window). A named on-call engineer with a backup. Model-version-change support included.
Red flag: “We’ll be available for questions for 30 days.” Vague, no SLA. “Best-effort support” — no commitment. No model-version-change support — the most common in-window incident in 2026, because frontier vendors deprecate models on a 6–12 month cadence.
Example fragments
Four annotated fragments. Model language, not legal advice — adapt with counsel for your jurisdiction.
Example 1: A milestone table
Section 2.1 — Milestone Schedule. The Engagement consists of the following four milestones. The Engagement clock begins on the Kickoff Date defined in Section 1.3. Each milestone payment is due upon Founder’s written acceptance per the acceptance criteria in Section 6.
Milestone Week Headline Deliverable Payment M1 Week 2 Eval-first PRD + capability-feasibility memo + eval set (30–80 cases, two-grader agreement above 80%) 30% of Total Fee M2 Week 6 Deployed Product with payment flow, 5–15 invited paying users, M1 eval set passing at agreed threshold 30% of Total Fee M3 Week 10 Hardening: auth, observability, eval-regression CI; 7 days unattended uptime; cost-per-query within budget 15% of Total Fee M4 Week 12 Documentation pack, prompt library, runbook, 30-day post-handoff on-call SLA 5% of Total Fee A signing fee of 20% of Total Fee is due upon execution.
What this does well: named milestones, week numbers tied to a defined kickoff, headline deliverables as nouns, payment percentages summing to 100%, acceptance gates that bind to a separate eval section.
Example 2: An eval acceptance criterion
Section 6.2 — M2 Acceptance. The Partner has delivered M2 when all three conditions are satisfied:
- The Product is deployed at the production URL defined in Section 1.4, with payment flow live and authentication enabled.
- The M1 Eval Set, executed against the deployed Product in production, returns “good” or “excellent” on no fewer than 80% of cases under the three-tier rubric defined in the M1 PRD.
- At least one paying user, invited per Section 1.5, has completed the core task end-to-end without engineer-in-the-loop assistance.
M2 acceptance is binary. The Founder shall provide written acceptance or rejection within 5 business days of Partner’s notice of M2 readiness. Rejection shall be accompanied by a written list of specific failures against the three conditions.
What this does well: three explicit, gradable conditions. Binary acceptance. A defined response window. A rejection-with-specifics requirement so disputes anchor to the document.
Example 3: An IP-ownership paragraph
Section 5.1 — Founder-Owned Work Product. Subject to Founder’s full payment of fees due as of the applicable date, the Partner irrevocably assigns to the Founder all right, title, and interest in: (a) the Application Code and repositories; (b) the Prompt Library, including all prompts and templates; (c) the Eval Set, including graded cases, rubric, and grader notes; (d) the Runbook; (e) the M1 PRD and all amendments. Assignment is effective at M4 Acceptance or, if the Engagement is terminated earlier, at termination.
Section 5.2 — Frontier-Model Contracts. The Founder holds the production contracts with each frontier-model vendor (Anthropic, OpenAI, Google, or substitute) on the Founder’s own billing from the start of M2. The Partner does not intermediate or mark up those contracts. Inference costs are direct vendor expenses, outside the Total Fee.
What this does well: names code, prompts, eval set, runbook, and PRD as distinct assignable items — no “the code” ambiguity. Includes the early-termination case. Carves out the model-vendor relationship as direct, not intermediated.
Example 4: A change-order procedure
Section 7 — Change-Order Procedure. Any modification to Scope, Milestones, Deliverables, or Total Fee shall be processed through these five steps. No Party is obligated to deliver or pay for any modification that has not completed all five.
- Trigger. Either Party proposes a change in writing to the other’s Engagement Lead, including a one-paragraph description and business reason.
- Sizing. The Partner returns a sized estimate in writing within 3 business days: engineering effort, calendar impact, proposed price (fixed add-on, defined cut, or both).
- Pricing. The change is priced as (a) a fixed add-on, (b) a defined cut to an existing Deliverable, or (c) a Phase 2 ticket outside this SOW. No time-and-materials within this SOW’s window.
- Approval. The Founder accepts or rejects in writing within 5 business days. The Partner does not begin work until the Change Order is executed.
- Logging. Every executed Change Order is appended as a numbered Amendment referencing the affected Milestone(s).
No change shall be implemented without an executed Change Order, regardless of perceived size or the Partner’s good-faith willingness to absorb it.
What this does well: five concrete steps with response windows on both sides. Names the absorbed-favor trap and refuses it. Binds change orders to numbered amendments so the document is auditable at termination.
The 3 sections most SOWs get wrong
Three sections account for the bulk of overrun risk. Under time pressure, audit these first.
Eval acceptance criteria (Section 6). Most SOWs we review — including from named, reputable AI agencies — do not name the eval set as a contractual acceptance gate. Diagnostic question: “What is the binary, gradable condition that triggers M2 acceptance?” If the answer is “we’ll know when we see it,” the section is wrong.
Change-order policy (Section 7). Most inherited templates use one sentence: “Any change requires mutual written approval.” Without the five-step procedure, the partner has unlimited optionality to absorb small changes that compound. Diagnostic question: “Walk me through the exact procedure for a 4-hour change request.” If the answer is “we’ll just handle it,” the section is wrong.
Post-launch on-call (Section 9). Most SOWs offer “30 days of support” as a vague good-faith promise. Diagnostic question: “What is the first-response SLA for a severity-1 incident at 11pm on day 22?” If the answer is “we’ll do our best,” the section is wrong. Vagueness here converts a clean engagement-end into a permanent advisory retainer.
The other six sections matter but fail less catastrophically — at the 5–15% overrun band, not the 30%+ band the eval-acceptance and change-order failures produce.
What to negotiate vs accept
Some clauses are structural — they reflect the 2026 AI build market and cannot be moved. Others are worth pressing on.
| Item | Posture |
|---|---|
| Frontier-model TOS pass-through | Accept — no partner can give you better terms than vendors give them |
| Model weights ownership | Accept — nobody owns the weights |
| 6–12 week engagement window | Accept — category definition |
| Founder-ownership of code, prompts, eval set | Accept — non-negotiable in defensible SOWs |
| Eval acceptance as a milestone gate | Accept — non-negotiable |
| Total fee | Negotiate within the posted 2026 range |
| Payment schedule front-loading | Negotiate — push signing fee toward 15–20% rather than 30%+ |
| On-call duration | Negotiate — 30 days is standard; 60–90 days is press-worthy on larger fees |
| Termination-for-convenience notice | Negotiate — 14 days is standard; 7 days is press-worthy |
| Change-order sizing window | Negotiate — 3 business days is standard; 2 is press-worthy |
| Partner’s reservation of marketing rights | Negotiate — many partners drop “marketing use” clauses entirely if asked |
Trying to negotiate the structural items signals procurement immaturity and burns down standing on the negotiable ones. Save the negotiating capital for the right column.
The 5-question signing checklist
Before counter-signing, run these five questions through the document in front of you.
- “What is the binary, gradable acceptance criterion for M2?” If the SOW does not name an eval-set pass threshold and a first-paying-user completion condition, the milestone is not acceptable.
- “Walk me through the change-order procedure step by step.” If the SOW does not contain a five-step procedure with response windows, the engagement is unbounded.
- “What does the founder own at handoff — code, prompts, eval set, runbook, customer data, model contracts?” If any of those six is silent or partner-retained, the handoff is not clean.
- “What is the post-launch on-call SLA?” If the SOW does not contain a first-response time, severity definitions, and an incident cap, “support” is a placeholder.
- “What happens at termination at M1, M2, or M3 — what does the founder receive?” If the SOW does not specify deliverable transfer-state at each milestone boundary, the engagement is not reversible.
A defensible SOW answers all five inside the document. A partner whose answers are “we’ll figure it out as we go” is selling time-and-materials with a fixed-fee label.
Book a 30-minute SOW review. Bring the draft you are reviewing — redacted as you prefer — your top three concerns, and a deadline. We say within the thirty minutes whether the document is defensible, which clauses to press on, and which to accept. Schedule the review.
For broader context on choosing the counterparty, see how to pick an AI development partner when you’ve never built software. For the category-level frame, see idea-to-product as a service. For the operating sequence the SOW encodes, see the idea validation playbook and the broader idea-to-product manifesto.
FAQ
What is the most common missing section in AI MVP SOWs?
Eval acceptance criteria. Most inherited templates list “testing” as a deliverable category and treat eval as internal QA. The eval set should be a named M1 deliverable, owned by the founder, and the basis for M2 acceptance. Without it, M2 acceptance collapses into a subjective sign-off, and the engagement converts to time-and-materials by default.
What pricing structure best contains overrun risk?
Milestone-billed fixed fees with each payment tied to acceptance. A defensible split for a $150K engagement: 20% at signing, 30% at M1, 30% at M2, 15% at M3, 5% at M4. Time-and-materials dressed as fixed-fee (“$150K estimated, billed weekly”) is the most common predatory structure; refuse it.
Who owns the prompts and the eval set at handoff?
The founder, in every defensible SOW. Prompts ship as a versioned library in the founder’s repo. The eval set ships with graded cases, rubric, and grader notes. A “partner-retained prompt library” clause is the most common predatory IP clause in 2026 AI MVP SOWs — refuse it. The eval set is what lets the founder survive a frontier-model upgrade without re-hiring the partner.
What is the absorbed-favor trap and how does the SOW refuse it?
The partner’s offer to “just handle” a small mid-engagement change without a change order. It feels generous and is structurally costly: small absorbed changes compound into scope creep and end as a 30%+ overrun argument at M3. The SOW refuses the trap by requiring an executed Change Order for every modification and naming the trap explicitly in the change-order clause.
How long should the post-launch on-call window be?
30 days is the 2026 market standard for a single $150K engagement. 60–90 days is reasonable to negotiate on larger fees. The window matters less than the SLA inside it — a 30-day on-call with a 4-hour first-response SLA on severity-1 incidents is more valuable than a 90-day window with “best-effort” language.
What if the partner’s frontier model gets deprecated mid-build?
A defensible SOW puts model-version-change support inside the on-call clause. If the founder’s primary model deprecates within the on-call window, the partner supports the swap at no additional fee. The 2026 deprecation cadence is roughly 6–12 months, so this is routine.
Can I sign an SOW without a PRD ready?
Yes — the planning week (M1) produces the PRD. The SOW references the PRD as a forthcoming section binding upon M1 acceptance. What you cannot do is fix the M2 fee before the M1 PRD is written. A partner who insists on locking M2 pricing before M1 is either pricing in heavy contingency or planning to use change orders to recover the gap.
What termination terms protect the founder if the engagement collapses?
Termination at clean milestone boundaries (M1, M2, M3) with transfer of work-to-date in deliverable-grade form. Mutual termination-for-convenience with 14 days’ notice and prorated payment. Termination-for-cause defined narrowly. Avoid any clause that retains partner ownership of work-to-date upon termination.
How do I tell whether an SOW template is AI-native or inherited?
Three checks. Is eval acceptance named as a contractual milestone gate? Are prompts and eval sets named as separately assignable IP items? Is the frontier-model contract carved out as direct to the founder? If any of the three is silent or partner-retained, the template is inherited and needs heavy modification.
What is the right page length for a defensible SOW?
Roughly 15–25 pages. Below 10, the document cannot carry the nine sections at the required specificity. Above 35, it is usually either over-lawyered with boilerplate or hiding scope-creep optionality in dense exhibit language.
Arthur Wandzel
