The proposal gets you the yes. The statement of work is what keeps the yes from becoming six weeks of unpaid archaeology into what someone "thought was included." Most solo operators have a proposal. Fewer have a real SOW. Almost nobody has the six sections below written tightly enough to settle an argument without a phone call.
Here's what a SOW actually is, which parts do the protecting, and the specific lines — exclusions, acceptance windows, revision limits — that separate a document that gets you paid from one that gets you argued with.
SOW vs proposal vs MSA, in one paragraph each
A proposal is a sales document. It exists to get a yes: what you'll do, what it costs, why you, how to start. It's allowed to be optimistic, and it's allowed to die in the client's inbox. Nothing in a proposal should be load-bearing.
A master services agreement (MSA) is the standing legal frame between you and the client: payment terms, IP assignment, confidentiality, liability, termination. It gets signed once and governs everything after. Most solo operators fold these terms into their service agreement and never say the acronym — fine. What matters is that the boring clauses exist somewhere signed.
A statement of work (SOW) is the per-project document that sits under that frame: this engagement, these deliverables, this price, this schedule. With repeat clients, the pattern is one MSA plus a short SOW per project. With one-off clients, it's a combined agreement with a SOW section. Either way, the SOW is where scope lives — and scope is where disputes live, so this is the document that has to be exact.
The six sections that matter
SOW templates run to twenty sections. Six carry the weight:
1. Objectives. Two or three sentences on what the client is trying to achieve — not what you're building, why. "Reduce checkout abandonment on the store" is an objective; "rebuild the checkout in React" is a task. The objective section is what you point at when a requested change doesn't serve it, and it's what keeps a wandering project anchored to a business reason.
2. In scope. A numbered list of exactly what you will deliver, each item concrete enough that a stranger could check it off. "Product page template built and styled" is in scope. "E-commerce improvements" is an argument in waiting. If a reader could interpret an item two ways, it's wrong.
3. Out of scope / exclusions. The most valuable section in the document — covered in detail below.
4. Milestones and deliverables. What ships when, and what "done" looks like for each: a URL, a file, a deployed build, a written report. Tie payment to milestones and you quietly solve most cash-flow anxiety on the side.
5. Acceptance criteria with a review window. How the client confirms each deliverable is accepted — and, critically, what happens if they don't respond. Covered below.
6. Change control. One short paragraph stating that anything outside the in-scope list is handled as a written change order with its own price and timeline. This sentence is the difference between scope creep being a negotiation and scope creep being a formality.
A useful test for all six: write each one for the bad day, not the signing day. On signing day everyone is friends and every clause feels excessive. The document earns its keep six weeks in, when somebody's boss asks why the thing they never mentioned isn't finished — and the answer is a section number, not a debate.
The exclusion lines that save projects
The in-scope list tells the client what they're buying. The exclusions list tells them what they're not — and clients read exclusions more carefully than anything else in the document, because it's the only section that might contain bad news. Write it as specific, concrete items, not categories:
Excludes: – Content entry or migration beyond 20 pages – Third-party plugin or theme licensing fees – Copywriting, photography, or asset creation – Support for Internet Explorer 11 – Changes to systems outside [named site or codebase] – Post-launch support beyond the 14-day warranty window
Each line on a list like that is a scar — something that once ate a week or an invoice. "Beyond 20 pages" exists because "migrate the content" once meant four hundred pages of PDFs. "IE11 support" exists because a stakeholder's nephew once tested the site on a museum computer. "Post-launch support beyond the warranty window" exists because "one quick question" has no natural endpoint. When the request arrives later, you're not declining anything — you're reading back a list the client already signed. That is the entire trick: exclusions turn a future argument into a lookup.
The acceptance-window trick
The quiet killer of solo project timelines is the deliverable that sits in the client's inbox — unaccepted, unrejected — while you can't invoice the milestone and can't cleanly start the next phase. The fix is deemed acceptance:
Each deliverable is deemed accepted five (5) business days after delivery unless the Client provides written notice of specific deficiencies within that window. Deficiency notices will reference the acceptance criteria above; corrections are made within [X] business days at no charge.
This is standard practice in professional-services contracts, not a trick in the unfair sense — the client still gets a real review period and a real remedy. What it removes is the indefinite maybe. Five business days is enough time for an honest review and short enough to keep a one-person business's schedule — and invoices — moving. Note the last line: corrections against the written criteria are free. That's what makes the window fair, and fairness is what makes it hold up in the only court that matters at this scale, which is the client's sense of whether you're being straight with them.
"Reasonable revisions" is a trap
If your SOW contains the phrase "reasonable revisions," you have outsourced the definition of your working week to whoever is most frustrated in any given month. Reasonable to whom, by what measure, decided when? The phrase survives because it sounds accommodating. What it actually accommodates is a fifth, sixth, and ninth round of changes, each one individually reasonable.
Replace it with a number and a definition:
Includes two (2) revision rounds per deliverable. A revision round is a single consolidated set of written feedback, returned within the acceptance window. Further rounds are quoted as change orders under the change-control section.
"Consolidated" is the load-bearing word. It kills the drip-feed — the Tuesday email, the Thursday addendum, the "one more thought" on Sunday — by defining a round as one batch. Clients adapt to this quickly, because it protects them too: consolidated feedback gets addressed in a single pass instead of being half-fixed three times.
The pattern across all three of these sections is the same: anything that feels awkward to write down will feel ten times more awkward to negotiate mid-project. The SOW is where awkward goes to become routine.
If you want the documents ready-made, the Client-Ready Business Templates ($19) include the statement of work with all six sections above, the change order it references, and the service agreement that carries the payment terms. For the cash-flow side — why milestone-based invoicing belongs inside a thirteen-week forecast — see the 13-week cash flow piece. The sections above work copied into a plain document; no stationery required.