Read an idea-to-product SOW the way a procurement officer would — section by section, with a red pen. Most non-technical founders read end-to-end, get to the price page, and counter on price. That misses where money leaks: acceptance criteria, change-order language, repo handover, kill-fee math. This page walks the 9 standard sections, names the credibility signals and red flags, and tells you which clauses partners actually move on.
The article assumes a draft SOW in front of you, a sign-by date in 7–10 days, and no lawyer on retainer. If that fits, read the idea-to-product manifesto for framing first.
Before you start reading
Three things next to the SOW. First, the partner’s proposal deck — the deck is marketing, the SOW is contract, and discrepancies are your first negotiation lever. Second, your eval set, or a written sentence describing what “good” looks like for the primary task; if you do not have this, defer signing — see what a defensible SOW looks like. Third, a printout of this checklist with a red pen.
Section 1: Scope and deliverables
Scope answers one question: at the end of week 12, what exactly does the partner hand you?
Look for. Scope reads like a fence — one product, one user persona, one primary task, one named frontier-model vendor (GPT-5, Claude Opus 4.8, or Gemini 2.5). Deliverables are artifacts — a repo, an eval set, a deployed URL, a PRD — not activities. Exclusions are explicit: “native mobile, SSO, SOC 2 attestation.”
Push back on. Aspirational language. “A production-ready AI product” does no procurement work and converts into change orders later. Catch-all clauses (“plus any additional features identified during the engagement”) invert scope-change burden onto you.
Negotiable. Most partners rewrite scope statements when you push on a phrase with substitute language. They will not add deliverables for free, but they will reframe vague ones into specific ones at no cost.
Section 2: Milestones and timeline
Calendar-driven SOWs (“Phase 1, weeks 1–4”) are the most common amateur tell. A credible engagement is milestone-driven.
Look for. Four named milestones: M1 (PRD and eval set complete), M2 (MVP deployed to first paying or pilot users), M3 (hardening complete), M4 (handoff plus a 30-day on-call window). Each has a one-line deliverable, a one-line acceptance criterion tied to Section 3, and a target week from a defined kickoff.
Push back on. Phase language with no acceptance criteria. Milestones describing partner activity (“design phase complete”) instead of founder-visible artifacts (“MVP deployed at app.yourdomain.com with 5 pilot users”). Calendar dates with no tie-back to deliverables.
Negotiable. Milestone ordering and the M1 deliverable list are highly negotiable. Partners will slide kickoff but resist compressing the build. The M4 on-call window is negotiable upward (60 or 90 days) for a material trade.
Section 3: Acceptance criteria
The most under-written section in 2026 idea-to-product SOWs. Acceptance criteria are how you stop paying when the work is not done.
Look for. Eval-based acceptance, not vibes-based. M1: PRD signed off, eval set with at least 50 graded cases delivered. M2: deployed system passes a stated percentage of the M1 eval set on a held-out split (typical target: 80%). M3: a stated hardening checklist complete and no regression below M2 pass rate. M4: on-call SLA in numeric terms (first response within 4 business hours on severity-1). The connection to eval-first scoping is what makes the document enforceable.
Push back on. “Acceptance upon client sign-off” with no objective criterion. “Considered accepted if the client does not object within 5 business days” — acceptance by exhaustion. “Production-ready” with no definition.
Negotiable. The eval pass-rate threshold is negotiable; the existence of a numeric threshold is not. A partner who refuses any numeric criterion is a fit problem, not a SOW edit.
Section 4: Pricing and payment schedule
Total fee matters less than how the tranches are structured. Structure tells you who is bearing risk.
Look for. Fixed-price milestone tranches. A defensible split for a $150K engagement: roughly 20% at signing, 30% at M1, 30% at M2, 15% at M3, 5% at M4. Each payment is gated on the corresponding acceptance criterion. Payment terms (net 15 or net 30) and invoice format specified. Model-vendor API spend is capped or pass-through at zero to ten percent markup.
Push back on. Front-loaded schedules (50% at signing, 50% at delivery) remove your only ongoing point of influence. T&M dressed as fixed-fee (“$150K estimated, billed weekly”) is the most common manipulative structure in 2026. Not-to-exceed caps are T&M with a ceiling. See the fixed-price contract clauses worth negotiating.
Negotiable. The tranche split is highly negotiable. Total fee is moderately negotiable (typically 5–15% for a fast sign). The hourly rate for out-of-scope work matters less than capping maximum billable hours without a change order.
Section 5: Change-control and scope-change
The change-order clause is where scope creep gets priced or absorbed. Most founders skip it.
Look for. Every modification to scope, milestones, deliverables, or fees requires a written Change Order signed by both parties. Change Orders state the modification, schedule impact, fee impact, and new acceptance criterion. The SOW names a Change Order template as an exhibit. For AI projects, change-control covers three axes — not two: scope, schedule, and model behavior (what happens if the frontier model deprecates, regresses, or changes pricing mid-build).
Push back on. “Minor changes will be absorbed by the partner at no cost” — sounds generous, structurally costly. It trains both parties to skip paperwork on small changes that compound into a 25%+ overrun by M3. Silence on model-version change. Any clause that lets the partner unilaterally substitute the named frontier model.
Negotiable. The Change Order template is highly negotiable. The model-substitution clause is highly negotiable — partners accept “no substitution without founder approval” because it costs them nothing today. The absorbed-favor language is non-negotiable: refuse it.
Section 6: IP, code ownership, and repo handover
Inherited from pre-AI templates — strong on source code, weak on four AI-specific assets: prompts, eval sets, fine-tunes, and infrastructure-as-code.
Look for. All work product assigned to the founder on a work-for-hire basis. The repo lives in the founder’s GitHub or GitLab org from week 1. Prompts ship as a versioned library in the founder’s repo. The eval set ships with graded cases, rubric notes, and a grader README. Fine-tunes ship as files plus training data and script. Infrastructure-as-code ships with secrets externalized to the founder’s vault. Handover is a named M4 deliverable with a checklist exhibit.
Push back on. Partner-retained IP clauses dressed as a “shared prompt library” or “reusable agent framework” — the most common predatory IP structure in 2026 idea-to-product contracts. Partner-owned repo with “transfer at handoff” language. Silence on eval-set or fine-tune-weight ownership. Any clause that lets the partner reuse your prompts or eval sets with other clients.
Negotiable. A non-confidential, anonymized case-study right is reasonable to grant. Repo-ownership timing is moderately negotiable (some partners insist on the build-time repo for sandbox isolation; demand admin access from week 1, full transfer by M2). The reusable-framework clause is non-negotiable.
Section 7: Data, security, and confidentiality
Two sub-topics pre-AI SOWs handle adequately, one they handle badly.
Look for. Mutual NDA covering the engagement plus a 3-year tail. PII handling defined: which datasets the partner accesses, how stored, who has access, what happens at engagement end. The piece most templates miss is eval-data handling. Eval sets often contain synthetic data that is real-shaped (customer-like records). The SOW should specify eval data is stored in your environment, accessed under a defined grant, and destroyed or returned at M4.
Push back on. Generic NDA with no PII specifics. Eval-data silence. Any language that lets the partner export your data, even aggregated, without written consent. Confidentiality tails under 2 years or over 5 years.
Negotiable. The confidentiality tail is moderately negotiable — a 2-year tail with a residual-knowledge carve-out is normal. Subprocessor lists are non-negotiable: demand them in writing as an exhibit, with right of approval over new additions.
Section 8: Warranty and post-launch support
The warranty section is what stands between you and a buggy MVP one week after the partner is paid.
Look for. A defined warranty window after M4 close, typically 30 days for a $150K engagement and 60 to 90 days for larger fees. Coverage: bugs in partner-built code at no additional fee, defined as deviations from M2 or M3 acceptance criteria. First-response SLA is numeric (4 business hours for severity-1, 1 business day for severity-2, 5 business days for severity-3). Exclusions: new features, model-vendor outages outside the partner’s control, founder-introduced regressions.
Push back on. “Best-effort post-launch support” is not a warranty. Warranty windows under 14 days. SLA language with “reasonable response time” and no numbers. Warranty excluding anything model-related — a 2026 AI build is mostly model behavior. Hourly billing for warranty fixes defeats the point.
Negotiable. Warranty length is negotiable upward for a material trade. SLA tiers are highly negotiable. Model-version-change support inside the warranty window is worth pushing for — the 2026 frontier-model deprecation cadence is roughly 6 to 12 months.
Section 9: Termination and exit
The termination clause protects you if the engagement collapses at M2. Most founders skip it. Read it last, but twice.
Look for. Termination for convenience by either party with 14-day notice. Termination at clean milestone boundaries (M1, M2, M3) with full transfer of work-to-date in deliverable-grade form, not WIP. A kill-fee formula = the lesser of (a) the unpaid balance on the current milestone tranche, (b) hours-worked-since-last-paid-milestone at a defined hourly rate. Termination-for-cause defined narrowly (material breach, insolvency) with a cure period of at least 10 business days. Source-code escrow is reasonable for engagements over $200K.
Push back on. Termination for convenience by the partner only — you should have symmetric rights. Termination-fee language requiring the full remaining contract value. Unilateral retention of work-to-date. Subjective definitions of cause (“loss of confidence”). Silence on the repo and deployed system at termination.
Negotiable. The kill-fee formula is highly negotiable on specifics and moderately negotiable on structure (full-balance kill-fees are out of market). The cure period: 10 to 20 business days is normal. Source-code escrow cost is moderately negotiable — partners try to push the escrow-vendor fee to the founder, which is reasonable to split.
Book a SOW review
If you are reading a draft SOW now and want a second set of eyes, SFAI Labs runs a 30-minute SOW review call for founders evaluating an idea-to-product engagement. No fee. The output is a marked-up PDF with section commentary and a prioritized push-back list.
Book a 30-minute SOW review — bring the draft and a 1-paragraph description of the idea. To see a sample first, the defensible SOW page walks an annotated example. For broader build economics, see the AI MVP economics playbook. For failure modes bad SOWs produce, see the runaway AI project anatomy. For “production-ready” framing in proposals, see decoding production-ready in AI agency proposals.
FAQ
How long should an idea-to-product SOW be?
Roughly 15–25 pages of body plus exhibits. Under 10 pages, the document cannot carry nine sections at the specificity an enforceable contract requires. Over 35 pages, it is usually over-lawyered or hiding scope optionality in dense exhibit language.
What is the difference between deliverables and acceptance criteria?
Deliverables are what the partner hands you (a repo, an eval set, a deployed URL). Acceptance criteria are the objective conditions under which you accept the deliverable and release the tranche. A defensible SOW pairs every deliverable with at least one acceptance criterion. Conflating the two is the most common failure in inherited templates.
Should I sign a fixed-price or time-and-materials SOW?
Fixed-price, milestone-billed, for an MVP under 12 weeks. T&M makes sense for long-running staff-augmentation, not a defined-scope build. A not-to-exceed cap on T&M is still T&M. Fixed-price pushes scoping discipline onto the partner — which is what you are buying.
What is a fair kill-fee?
The lesser of (a) the unpaid balance on the current milestone tranche, and (b) hours-worked-since-last-paid-milestone at a defined hourly rate ($150–$250 for 2026 senior engineering time). Any kill-fee requiring the full remaining contract value is out of market — refuse it.
Who owns the model weights and fine-tunes?
You do, if the SOW says so. A defensible SOW assigns all model artifacts (fine-tunes, LoRA adapters, training data, scripts, prompt libraries, eval sets) to the founder as work product. Some partners retain a “shared prompt library” or “framework” — refuse it. It is the most common predatory IP clause in 2026 AI MVP contracts.
What happens to eval data after the engagement ends?
The SOW should specify destruction or return at M4 close. If eval data contains real or real-shaped customer records, demand a deletion certificate. Subprocessor obligations apply. This clause is often missing from inherited templates.
Can I get a sample SOW before signing?
Yes, and you should ask. A partner who refuses to share a redacted sample of a prior SOW is either inexperienced or hiding something. Redaction of client names and dollar amounts is fine; refusal to share the structure is a signal. See an annotated example SOW.
How do I push back without nuking the relationship?
Push back in writing, in the document, with proposed substitute language — not over a call. The written form is less personal and gives the partner room to respond on the merits, not the tone. Frame pushback as risk-sharing — “this clause asymmetrically carries my risk; here is a version that splits it evenly.”
What if the partner refuses to commit to numeric acceptance criteria?
Walk. A partner who will not commit to a numeric pass-rate on a held-out eval set in 2026 is either not running evals or unwilling to bear delivery risk — either case is fatal for a fixed-price engagement. If they say “every project is different,” have them write M2–M4 of the SOW after you do M1 together, once the eval set exists.
Key takeaways
- Read the SOW section by section, not as a flowing document.
- Acceptance criteria are the most under-written section — refuse subjective sign-off language.
- Pricing tranches matter more than total fee; insist on milestone-gated payments.
- Kill-fee formula and Change Order template are the two levers founders most often miss.
- Partners move on phrasing, payment timing, warranty length, and model-substitution. Not on work-for-hire IP or US governing law.
- Push back in writing with proposed substitute language, not on calls.
Arthur Wandzel
