What a Software Development Statement of Work Must Include
A software development statement of work turns a proposal into something you can hold a vendor to. Here is what each section must say, an outline to copy, and the gaps that cause disputes.
A software development statement of work (SOW) is the document that says exactly what will be built, how you will know it is done, when each piece arrives, what it costs, and what happens when something changes. The RFP asked the question, the proposal answered it, and the master services agreement sets the legal ground rules. The SOW is where the actual project lives.
If you read only one document before signing with a developer, read this one against the proposal that won. Most disputes between businesses and software vendors are not about bad code. They are about two honest parties remembering a different version of "done." A good SOW settles that because the answer is on page three.
What is the difference between a SOW, an RFP, and an MSA?
Three documents, three jobs.
The RFP (request for proposal) is yours. It describes your problem and asks vendors how they would solve it and for how much. It is a question, not a commitment. If you have not written one, see how to write a software brief or RFP.
The MSA (master services agreement) is the legal frame across projects: confidentiality, liability caps, indemnity, governing law, dispute resolution. You sign it once and it sits behind every SOW that follows.
The SOW is the project-specific contract. It inherits the MSA's legal terms and adds the particulars: this scope, these deliverables, these dates, this price. When a vendor says "that is out of scope," or you say "that is not what we agreed," this is the document you both open.
Small projects often fold the MSA terms into one agreement with the SOW attached. That is fine. A proposal plus a handshake is not, and it is how many small business software projects start.
What sections does a software SOW need?
Here is the structure we use. Each section answers a question a future, annoyed version of you will ask.
1. Background and objectives
Two or three paragraphs: the business problem and how success will be measured ("quote turnaround from two days to two hours"). A feature that serves the stated objective is hard to call "out of scope" later; one that does not is easy to challenge.
2. Scope
What is in, and in the same detail, what is out. In-scope is a list of features, one sentence each, grouped by user type: "An admin can export all invoices for a date range as CSV." Out-of-scope is what a reasonable person might assume is included but is not: mobile apps, data migration, content writing, unnamed integrations, hosting setup.
If scope is still fuzzy, do not sign a fixed-price SOW. Sign a short discovery SOW whose deliverable is the real scope. More on that in fixed price vs time and materials.
3. Deliverables
Scope is what the software does. Deliverables are what gets handed over: the source code repository, deployed environments, documentation, design files, test results, a handover session. Each has a format and a destination ("code pushed to a GitHub repository under the client's organization account").
4. Acceptance criteria
The most skipped section and the one that prevents the most disputes. For each deliverable: how you will test that it is done, who tests it, how many business days you have, and what silence means (most SOWs treat silence after 10 business days as acceptance, which is fine as long as you know it).
Criteria should be checkable by a non-engineer. "Login works" is not one. "A valid email and password reaches the dashboard in under three seconds on staging; an invalid password shows the error message in Appendix B" is.
5. Milestones and timeline
A table with four columns: milestone, vendor deliverable, client dependency (the copy, approvals, and access you must provide), payment released. Clutch's September 2026 pricing data puts the typical web development project at nine months, long enough to lose a stakeholder or change your mind. Client dependencies make it clear whose month slipped. Wellingtone's March 2026 State of Project Management release found only 36% of organizations mostly or always finish projects on time, and slow client approvals are one of the quietest reasons.
6. Assumptions
Everything the vendor relies on but does not control: that your existing API returns what its documentation claims, that a named person on your side approves designs within five business days. Each failed assumption becomes a change request. Read this list as your own to-do list.
7. Change control
How a change gets proposed, estimated, approved, and paid for: a one-page change request, a vendor estimate of hours, cost, and timeline impact within a stated number of days, written approval before work starts. The hourly rate for changes is written here, not negotiated later. Change control is not bureaucracy. It lets scope evolve without the price evolving in secret.
8. Intellectual property
Who owns the code, designs, and documentation once paid for. The common answer: the client owns deliverables created for them on full payment; the vendor keeps its pre-existing tools and grants a perpetual license to use them inside the deliverables; open-source components stay under their own licenses, listed in an appendix. If neither the SOW nor the MSA mentions IP, fix that before signing.
9. Payment schedule
Tie payments to accepted milestones, not calendar dates, so money moves when work is proven. State the deposit, invoice terms (net-15 or net-30 is typical), and what happens on late payment (work pauses after a stated number of days). Vendors will push for firm terms, and that is fair: a March 2026 Bluevine survey found 59% of US small businesses experience late payments at least occasionally. Clear triggers protect both sides.
10. Warranty and support
How long after acceptance the vendor fixes defects free (30 to 90 days is common), what counts as a defect versus a change, and what support costs after that. Price post-launch support separately; folding it into the build price hides both numbers.
11. Termination and handover
How either side exits early, what is paid for work done, and what is handed over regardless: all code to date, credentials, documentation, a transition session. This section matters most when the relationship is already going badly, which is exactly when you cannot negotiate it. We see the cost of skipping it every time we take over a software project from another developer.
Is there an outline I can copy?
Yes. Paste this into a document and fill it in with your vendor.
- Background and objectives (problem, success measures)
- Scope (in scope by user type; out-of-scope list)
- Deliverables (format, destination, owner)
- Acceptance criteria (who tests, test window, silence rule)
- Milestones (vendor deliverable, client dependency, payment released)
- Assumptions
- Change control (request form, estimate turnaround, hourly rate)
- Roles and communication (one decision-maker per side, cadence, response times)
- Intellectual property (deliverables, pre-existing tools, open-source appendix)
- Payment schedule (deposit, triggers, terms, late payment)
- Warranty and support (defect window, defect definition, support pricing)
- Termination and handover (exit terms, payment for work done, handover list)
- Appendices (user stories, designs, third-party licenses, environments)
A SOW for a $40,000 internal tool should run six to ten pages. Shorter and sections are missing. Much longer and nobody will read it, which is its own kind of missing.
What gaps in a SOW cause disputes?
Scope with no out-of-scope list. Every unstated expectation becomes a fight about whether it was "obviously included."
No acceptance criteria, or criteria only an engineer can check. "Done" becomes a matter of opinion.
Vendor dates with no client dependencies. You take three weeks to approve designs, launch slips, and the SOW blames the vendor. Cautious vendors pad the timeline to cover this, and you pay for the padding.
A change process nobody uses. Changes get agreed in Slack and disputed at invoice time. Even small changes deserve a written two-line confirmation.
IP that transfers "on completion" with no definition of completion. Tie it to final payment, and keep the code in your repository from day one.
No handover clause. The project ends badly and the vendor holds the only copy of everything.
We write a SOW for every Premier Logic project and expect clients to mark it up. Its acceptance criteria are written so an operations lead can test them without us in the room, because we measure work in hours returned to the business, and that needs a clear "finished."
Quick answers
Does a small project really need a SOW?
If it costs more than a month of someone's salary, yes. A SOW for a $15,000 project can be four pages; the sections stay the same and the detail shrinks. Not having one shows up when the project is 80% done and you disagree about the other 20%.
Can a SOW be changed after it is signed?
Yes, through its own change control section. Each approved change request amends scope, price, or timeline in writing. A project with undocumented changes is a dispute waiting for an invoice.
What is the difference between scope and deliverables?
Scope describes what the software does. Deliverables are the things handed over: code in your repository, deployed environments, documentation, design files. Complete scope with missing deliverables is how businesses end up with working software they cannot access or maintain.
Should a fixed-price SOW still include an hourly rate?
Yes. The fixed price covers the agreed scope. The hourly rate covers change requests and out-of-scope work. Without it, every change becomes a fresh negotiation at a moment when you have little room to push back.
Next step
If you have a proposal in hand and want a second pair of eyes before it becomes a contract, book a free call. Tell us what you are building and with whom, and we will go through the draft SOW (or the gaps where one should be) and send a written recommendation afterward. You keep the notes whether you hire us or not. Start here.
