Statement of Work Template (2026): A Free, Agency-Ready SoW

Quick answer (July 2026): A statement of work template needs nine sections to be usable: project overview, objectives, scope, explicit out-of-scope, deliverables, timeline and milestones, fees and payment schedule, assumptions and dependencies, and a change-control clause. The free template below covers all nine. For agencies shipping AI app builds, five extra clauses (platform, IP and source ownership, migration, capped revision rounds, and hosting plus data residency) are what actually keep a fixed-price engagement profitable.

Most statement of work templates you find online were written for procurement departments buying office furniture or a facilities contract. They are fine at defining scope and deliverables. They are silent on the two things that quietly drain margin from a modern agency: uncapped iteration on an AI-generated codebase, and who owns the code when the engagement ends.

This is the template we hand to agency owners who bill fixed-price AI builds. It starts with a complete, copy-paste statement of work you can adapt in an afternoon. Then it covers the AI-native clauses that generic templates leave out, with the reasoning behind each one, so you can decide what belongs in your own version.

None of this is legal advice. It is a practical drafting checklist. Run the final document past a lawyer in your jurisdiction before you sign anything that matters.

What a statement of work actually needs

A statement of work is the document that turns a proposal into a contract you can deliver against. A master service agreement (MSA) sets the legal relationship once. Each project then gets its own SoW that references the MSA and defines that specific engagement. If you do not have an MSA, the SoW has to carry the legal weight on its own, which is one more reason to be precise.

Every workable SoW answers nine questions. Miss one and you have left room for a dispute:

Section 4 (out of scope) and section 9 (change control) are the two that inexperienced teams skip, and they are the two that cause almost every fixed-price loss. If you write nothing else carefully, write those.

The free statement of work template (copy and paste)

Copy the block below into your document editor, replace the bracketed fields, and delete the guidance notes in italics. It is deliberately plain so it drops cleanly into a Google Doc, a Word file, or a Confluence page.

STATEMENT OF WORK

This Statement of Work ("SoW") is entered into on [DATE] between
[AGENCY LEGAL NAME] ("Provider") and [CLIENT LEGAL NAME] ("Client"),
and is governed by the Master Service Agreement dated [MSA DATE]
(or, if none, by the terms set out in this SoW).

1. PROJECT OVERVIEW
[One paragraph: what is being built, for whom, and the business
outcome it supports.]

2. OBJECTIVES
[Bullet list of measurable objectives. Example: "Launch a customer
portal that lets end users self-serve invoices, reducing support
tickets by a target of 30 percent within 90 days of launch."]

3. SCOPE OF WORK
[Enumerated list of the work included. Be specific about features,
screens, integrations, and environments.]

4. OUT OF SCOPE
[Enumerated list of work explicitly excluded. Example: native mobile
apps, data migration from legacy systems, third-party license costs,
content entry, ongoing maintenance after handoff.]

5. DELIVERABLES
[Table or list. For each deliverable, name the artifact and its
format. Example: "Production web application deployed to Client's
hosting; source code delivered as a Git repository; admin
documentation as a PDF."]

6. TIMELINE AND MILESTONES
[Milestone table with dates and the acceptance criteria for each.
Tie payments to milestones in section 7.]

7. FEES AND PAYMENT SCHEDULE
Total fixed fee: [AMOUNT].
Payment schedule:
- [X percent] on signature
- [X percent] on [milestone]
- [X percent] on final acceptance
Invoices are due within [N] days. Late payments pause work.

8. ASSUMPTIONS AND DEPENDENCIES
[List. Example: "Client provides brand assets, API credentials, and a
single point of contact within 3 business days of signature. Delays
in Client dependencies extend the timeline day for day."]

9. CHANGE CONTROL
Any change to scope, deliverables, or timeline is handled through a
written change order signed by both parties before the work begins.
A change order states the additional fee and the schedule impact.
Work outside this SoW is not performed without an approved change
order.

10. ACCEPTANCE
Client has [N] business days after delivery of each milestone to
accept or to submit a written list of defects. Absent a written
response within that window, the milestone is deemed accepted.

Signed:
Provider: ______________________  Date: __________
Client:   ______________________  Date: __________

That is a complete, defensible statement of work for a straightforward services engagement. If you build ordinary software or run a general agency, you can stop here.

If you build AI app builds, the next section is where the money is.

Five clauses generic SoW templates leave out

Generic templates, including the good ones from Atlassian and the usual document platforms, assume a predictable build. AI app builds are not predictable in the same way. The codebase is generated, iteration is cheap and therefore easy to over-consume, and the platform choice has consequences that outlast the project. These five clauses, layered on top of the nine sections above, are the ones we see protect agency margin in practice. Our SoW template for fixed-price AI app builds goes deeper on each; here is the short version.

1. Name the platform

State which builder the application is created on. Whether the app is generated on Lovable, Bolt, or another AI app builder changes what you can promise about export, hosting, and long-term maintenance. A client who later wants to move the app needs to know what they are moving. Naming the platform in the SoW also protects you: if the client insists on a platform with known export limits, that is now a documented Client decision, not a Provider defect.

2. IP and source-code ownership

Say plainly who owns the generated source at handoff, and when ownership transfers. The common and clean answer is that ownership transfers to the Client on final payment. Be explicit that ownership means the exported source code in a Git repository, not merely access to a hosted editor. Builders differ sharply here: some let you download and own the full source, others keep you inside a proprietary environment. If the platform cannot deliver portable source, the SoW should say so, so nobody assumes otherwise.

3. Migration and exit

Define what handoff includes. A one-line clause saves a two-week argument: "Provider delivers the exported source repository, a running production deployment on Client-owned infrastructure, environment variables documented, and one 60-minute handoff call. Migration of the application onto Client infrastructure beyond this is a separately scoped change order." Exit terms are not pessimism. They are how you keep a good client relationship from souring at the finish line.

4. Capped revision rounds

This is the single clause that most often turns a profitable AI build into a loss. Because prompting a builder for another variation is nearly free for the client to ask, revision requests expand to fill whatever space you leave. Cap them. "This SoW includes up to two rounds of revisions per milestone. Additional rounds are billed at [RATE] per hour or scoped as a change order." Pair this with your effective hourly rate so the overage rate reflects real delivery cost, not a guess.

5. Hosting and data residency

State where the app runs and where data lives after handoff. For clients with EU users or regulated data, data residency is a real requirement, not a nicety. Specify the hosting target, who pays for it, and for how long. If you host for the first year as part of the fee, say when that ends and what the client pays afterward, so year-two hosting does not silently become your problem.

A worked example: the same build, two SoWs

Consider a fixed-price internal tool build quoted at 18,000 dollars. The difference between a generic SoW and an AI-native one is not the price. It is what happens in month two.

Same deliverable, same headline price. The AI-native SoW protects roughly the margin that the revision cap alone recovers, which on an 18,000 dollar build is frequently the difference between a healthy and a break-even engagement. For how those margins vary by agency size, see our rate-card benchmarks by agency archetype.

How to use the template

1. Start from an MSA if you have one, and reference it in the SoW header. If not, the SoW carries the legal weight, so tighten sections 9 and 10.
2. Fill sections 1 through 10 for the specific project. Do not reuse last project's out-of-scope list without editing it.
3. Add the five AI-native clauses when the build runs on an AI app builder. Delete them for a plain services engagement.
4. Tie every payment in section 7 to a milestone in section 6. Never invoice against time on a fixed-price SoW.
5. Write the out-of-scope list before the scope list. It is easier to see what to exclude when you have not yet talked yourself into including it.
6. Have a lawyer review the final document. This template is a drafting aid, not legal counsel.

Common mistakes

• No out-of-scope section. Silence is read by the client as "included."
• Revisions left uncapped. On AI builds this is the fastest route to a loss.
• Milestones without acceptance criteria. "Done" needs a definition both parties agreed to in advance.
• Ownership left to assumption. State it, and tie transfer to final payment.
• Copy-pasting a SoW from a different project. The out-of-scope list and assumptions are project-specific. Reusing them verbatim is how excluded work sneaks back in.

If you take one thing from this

A statement of work does not protect you by listing what you will build. It protects you by naming what you will not build, and what happens when the client asks anyway. On AI app builds, that means an out-of-scope section, a revision cap, and a written ownership clause. The rest is formatting.