TLDR
The seven sections every software scope of work needs are: objective, deliverables, acceptance criteria, timeline, change order process, exclusions, and payment terms. The most-missed section is exclusions. The second most-missed is change order process. Both failures produce scope creep. Download the free scope of work template at the bottom of this post.
A scope of work is the difference between a 6-week sprint and a 16-week death march. We have signed 60 plus dev retainers at ScubaDev and one pattern holds: the engagements that stayed in scope had a scope of work with these seven sections filled in before kickoff. The ones that went sideways had a scope document that was missing at least two of them. This post walks through the seven sections, shows the one-page version we actually use, and links to the free downloadable scope of work template we keep in our template pack.
Why scope of work documents fail
Three failure patterns, observed across 60 plus software engagements.
Pattern one: no acceptance criteria. A scope that says “build a customer dashboard” is not a scope, it is a wish. Acceptance criteria turn a wish into a bill of materials. “Customer dashboard with the following 7 widgets, each pulling from the following 3 data sources, rendered on mobile and desktop, tested in Chrome and Safari.” That is a scope. The first version is a fight you are going to have eventually. Have it before kickoff.
Pattern two: no exclusions. Exclusions are the “this is not included” list. No exclusions means anything the client asks for is a fight to decline. Real exclusions list the obvious omissions (SEO, ongoing maintenance, hosting fees, third-party tool subscriptions) and the non-obvious ones (data migration from a previous system, user training, SOC 2 evidence collection).
Pattern three: no change order process. Scope creep is not the enemy. Unmanaged scope creep is. A 1-page change order form, a fixed rate for changes, and a written rule like “changes go in the backlog for next sprint” keeps the primary scope clean and the relationship honest.
The 7 sections every software scope of work needs
Below is the structure we use. This is the abbreviated public version. The fully annotated Word and PDF versions with lawyer-reviewed clauses live in the Template Pack.
1. Objective
One sentence. What business outcome does this project produce. Not “build a CRM” but “cut lead-to-first-call time from 48 hours to under 15 minutes.” The objective is the north star that settles every later scope dispute. If a feature request does not serve the objective, it is a change order.
2. Deliverables
A numbered list of artifacts. For software this usually means: production code in a specified repo, deployed to a specified environment, with documentation at a specified URL, with handoff to a specified person. Be literal. “Repo at github.com/client/project with main branch deployed to app.client.com, README at /README.md, handoff to CTO Jane Smith” is a real deliverable. “Working software” is not.
3. Acceptance criteria
For each deliverable, a written definition of “done.” For features, this is user stories plus test conditions. For artifacts, this is file locations and documentation standards. The acceptance criteria are what you sign off on at the end. If they are vague, the sign-off is a fight.
Per the Pragmatic Engineer 2025 post on scope, acceptance criteria should be testable in under 30 minutes per deliverable. If your acceptance test takes longer than that, the criteria are not written tightly enough.
4. Timeline
Milestones with dates. Not “6 weeks from start” but “Milestone 1: architecture approved by Feb 15, Milestone 2: first feature shipped to staging by Mar 1, Milestone 3: full scope on production by Apr 15.” Dates let both sides track drift. Week-counts let the timeline slide invisibly.
Include a contingency clause. Two weeks of slack for unknowns is standard. If the engagement is high-risk (data migration, third-party dependencies, unclear specs), 20 percent slack is appropriate. Dependencies the client owns (API access, content, legal sign-off) get called out here with the date they are due.
5. Change order process
The most skipped section and the one that prevents the most fights. Three pieces.
One. Who can request a change. Usually the client-side project lead, not any stakeholder. This prevents the pattern where a VP walks into a meeting and verbally reshapes a feature.
Two. How changes get priced. We use a fixed rate per change request tier: minor (under 4 hours of work) is included in the retainer up to a monthly cap, major (over 4 hours) is a written change order with its own price and timeline. The rate should be in the scope.
Three. How changes get approved. Written approval, usually by email reply, before work starts. No verbal change orders. The moment a change starts without paperwork is the moment the engagement goes sideways.
6. Exclusions
A bullet list of what is specifically not included. Our default exclusions for software engagements:
- Hosting and infrastructure costs
- Third-party subscription costs (Stripe, SendGrid, Auth0, etc)
- Content creation (copy, imagery, video)
- SEO strategy or content marketing
- Ongoing maintenance after handoff
- User training and documentation beyond the technical README
- Data migration from existing systems
- Compliance evidence (SOC 2, HIPAA, PCI) unless specifically scoped
- Design work beyond what is included in the deliverables
Exclusions are not adversarial. They set the buyer’s expectations. A scope without exclusions leaves the agency to tell the client “no” on every request, which is the fastest way to poison a relationship.
7. Payment terms
Net 15 or net 30. First payment due at kickoff. Late payment clauses. Milestone payments if the engagement is fixed-price. Retainer billing dates if it is a subscription. Include the right to pause work if payment is overdue past X days.
For retainer engagements, include the pause and cancellation policy. Subscription dev studios popularized “pause any time, cancel any time with notice.” We use the same structure on most engagements because it keeps clients committed only when they have work to queue.
What goes in the Master Services Agreement instead
A scope of work handles project-specific terms. A master services agreement handles the relationship-level terms: confidentiality, IP ownership, liability caps, warranty, indemnification, governing law. Most firms sign one MSA at the start of the relationship and reference it in every subsequent scope of work. This is faster than negotiating a new contract every time.
If you are signing your first dev engagement, you want both. The Template Pack includes the MSA, SOW, and retainer agreement as a set with cross-references.
How we use this at ScubaDev
Three specifics because a template post that does not show its own work is not trustworthy.
We require a signed SOW before any code gets written. No exceptions. A “trial sprint” is not an exception because it is itself a scoped engagement with its own mini-SOW.
We use a 1-page SOW template for sprints under $20K and the full 7-section template for everything larger. The 1-pager has the same 7 sections, just shorter. The full template has lawyer-reviewed boilerplate for liability and IP.
We review the exclusions list as the last step in every scope. Our rule is “if we cannot think of 5 things to exclude, we have not thought hard enough about what this engagement is not.” This single discipline has prevented more scope creep than every other process we run.
Red flags in a client’s own paperwork
Not every engagement starts with your scope. Sometimes the client has their own. Flags to look for:
Indemnification clauses that are not reciprocal.
You indemnify them for your work, fair. They indemnify you for their content and data, also fair. One-way indemnification is a no.
IP assignments that include your tools and frameworks.
The code you ship is theirs. The reusable patterns, templates, and internal tools you brought to the engagement are yours.
Warranties with no time or scope limit.
Standard software warranty is 30 to 90 days post-delivery for bugs in shipped code. Unlimited warranty is a liability tail you cannot price.
Non-compete clauses that prevent you from working in their industry.
Reasonable non-solicit (of their employees and direct customers) is standard. Non-compete by industry is not.
FAQ
1 to 2 pages for engagements under $20K. 3 to 5 pages for larger. The full Template Pack version is 5 pages because it covers enterprise cases.
For a standard engagement, no. For regulated industries (healthcare, finance, government), yes. Our Template Pack includes the notes on what needs legal review.
Yes, if both parties sign. We use PDFs with digital signatures for the audit trail. Google Docs work for drafts.
Functionally identical terms. “Scope of Work” is slightly more common in software. “Statement of Work” is slightly more common in enterprise consulting.
Annually at minimum. When any engagement goes sideways in a way the template could have prevented, update the template. Every scope document we run at ScubaDev is at least version 8.