Statement of Work (SOW) template
The SOW is the contract engine: deliverables page by page, acceptance criteria per milestone, change control, and exclusions named. Fill it once and "scope creep" stops being a risk.
A contract without a SOW is a promise; a SOW without acceptance criteria is a mood. This template is the operating document every milestone bills against — the expanded companion to the contract guide and the natural next step after the brief. Write it once, honestly, and most disputes become impossible: every “I thought” was a blank line in this document.
The fields, with guidance
Deliverables
Listed, not described. Every page, feature, integration and document — if it is not on the list, it is not in the price.
Example: 6 pages (Home, About, Services ×2, Contact, Privacy); contact form routing to two inboxes; blog section; GA4 + Search Console.
Acceptance criteria
The test each deliverable must pass. “Looks good” is not a criterion; “renders correctly on iOS Safari and Chrome Android, form submissions received and confirmed” is.
Example: Contact form: submissions arrive at both inboxes within 2 minutes with spam protection active; verified on staging.
Milestones
Delivery + acceptance + payment per stage. The rhythm that keeps both sides honest.
Example: M1 Design approved (30%) · M2 Build on staging (40%) · M3 Launch + handover pack (30% minus deposit split).
Timeline
Dates with dependencies stated — especially client-side ones (content, approvals, access).
Example: M1 by 15 Mar (requires content by 8 Mar); M2 by 12 Apr; launch week of 26 Apr.
Client responsibilities
The other half of the schedule. Late inputs move dates — say so here, kindly and clearly.
Example: Content for all pages by 8 Mar; hosting account created by 10 Mar; feedback consolidated within 3 working days per review round.
Exclusions
What the price does not include. Naming exclusions is the single highest-leverage SOW section.
Example: Excludes copywriting, photography, data entry beyond 20 products, SEO content strategy, ongoing maintenance (available separately).
Change control
One paragraph: changes are written, priced and scheduled before they are built. No verbal scope.
Example: Changes via written change note stating impact on cost and timeline; signed by both parties before work begins.
Payment terms
Amounts, triggers and terms per milestone, plus invoice mechanics.
Example: 30% deposit at signing; milestones invoiced on acceptance, due net-7; final on launch acceptance. Bank transfer, USD.
IP & handover
Deliverables transfer on final payment; handover pack itemised.
Example: On final payment: repository, all accounts in client name, documentation and runbook delivered per handover checklist.
Warranty & exit
The defect window and the kill-fee logic — clean exits keep projects civilized.
Example: 30-day defect window post-launch; termination at milestone boundary pays completed work + WIP, delivers everything to date.
Copy this block
STATEMENT OF WORK — [PROJECT]
1. DELIVERABLES
- [Page/feature/integration/document — listed, not described]
- [Add every item; unlisted = excluded]
2. ACCEPTANCE CRITERIA
- [The test each deliverable must pass, verifiable on staging]
3. MILESTONES & PAYMENT
M1 [name] — [deliverable] — [acceptance] — [£/%]
M2 ...
Final — launch + handover pack — [%]
4. TIMELINE
[Dates, with client-side dependencies named]
5. CLIENT RESPONSIBILITIES
[Content, access, decisions — with deadlines]
6. EXCLUSIONS
[Everything the price does not include]
7. CHANGE CONTROL
Changes in writing: impact on cost and timeline, signed
before work begins.
8. PAYMENT TERMS
Deposit [%] at signing; milestones net-7 on acceptance;
final on launch acceptance. [Currency/method]
9. IP & HANDOVER
Deliverables transfer to client on final payment.
Handover: repository, accounts, credentials, documentation.
10. WARRANTY & EXIT
30-day defect window. Termination at milestone boundary:
completed work + WIP paid and delivered.
Signed:
_______________________ _______________________
[CLIENT] [DEVELOPER] Date: [DATE]
Plain text on purpose — pastes cleanly into email, docs and project tools.
The working version of this document runs every project here — the published terms mirror it. Use it with any developer; it travels.
Quarterly, and only when the numbers move
Get the rate report before you negotiate.
Updated rate bands across the major stacks and regions, plus what changed and why. No other email.