Software Statement of Work Explained: How to Read and Compare Development Quotes

A software statement of work (SOW) is the document that says exactly what a developer will build, how, by when, for how much and what counts as finished. It is where most of the risk in a software project is either controlled or hidden. Two quotes with the same headline price can describe very different projects once you read their assumptions, exclusions and change process.

We regularly quote against competing proposals, and the biggest differences are rarely the day rate. This guide explains what a good SOW contains, where risk hides, how to compare quotes fairly and the red flags to watch for.

What a statement of work is

A statement of work sits alongside your main contract or terms of business. The contract covers the legal relationship: liability, confidentiality, termination and so on. The SOW covers the project itself: what will be delivered, how it will be delivered and what both sides must do.

For custom software, the SOW is the single most important document you will sign. It turns an idea discussed in meetings into a defined piece of work that can be priced, built, tested and accepted. If something matters to you and it is not in the SOW, assume it is not included.

Sections a good SOW has

A well-written software statement of work usually includes:

1. Background and objectives. Why the project exists and what it must achieve.
2. Scope. The features and deliverables, described clearly enough that both sides agree what "done" looks like.
3. Out of scope. What is explicitly not included.
4. Assumptions. What the price depends on being true.
5. Client responsibilities. Content, data, access, decisions and feedback times.
6. Timeline and milestones, with dependencies.
7. Acceptance criteria. How each deliverable will be tested and signed off.
8. Change control. How new requests are estimated, approved and scheduled.
9. Price and payment schedule.
10. Warranty and support after launch.
11. Intellectual property and access, including code, repositories and hosting accounts.

Assumptions and exclusions

This is where quotes quietly differ. Assumptions are the conditions the price depends on. Exclusions are things the developer is not doing. Both are reasonable in themselves. The problem comes when they are vague, buried or surprising.

Common assumptions that change the real cost:

• "The client will provide all content and product data in the agreed format."
• "Integration uses the third party's existing, documented API."
• "Up to two rounds of design revisions."
• "Existing data is clean and needs no transformation."

Common exclusions to look for:

• Data migration from old systems.
• Hosting setup, monitoring and backups.
• Testing on older browsers or devices.
• App store submission, training or user documentation.
• Support after a short warranty period.

Watch for phrases such as "standard functionality", "as discussed" or "similar to", which mean different things to different people. Ask for them to be replaced with specific descriptions.

Comparing quotes fairly

Do not compare totals first. Put every quote into one table, line by line, then look at the price.

When we have compared our own quotes with competing proposals for the same project, the gaps usually came from what each proposal assumed the client would do, what it left out and how changes would be charged. A cheaper quote that excludes data migration and assumes perfect data can easily end up the more expensive project.

It also helps to understand the technical choices behind each quote. Our guide to choosing a web app tech stack explains what to ask.

Change control

Requirements change as soon as real users see software. That is normal. A good SOW does not pretend otherwise. It sets out how changes are handled:

1. The change is described in writing.
2. The developer estimates its effect on cost and timeline.
3. You approve or decline it before work starts.
4. The approved change is added to the scope and schedule.

Fixed-price projects rely on tight change control, because any change alters the fixed price. Time-and-materials projects rely on regular reporting, so you always know where the budget stands. Either can work, as long as the process is written down.

Payment milestones and IP

Payments should be tied to deliverables you can see and test, not just dates. A typical pattern is a deposit to start, stage payments on accepted milestones and a final payment on launch or acceptance. Be cautious about paying most of the price before anything is delivered.

Intellectual property matters just as much. The SOW or contract should say that ownership of the code written for you transfers to you, usually on payment. It should also list any third-party or open-source components and their licences, and confirm you will have access to the code repository, hosting accounts and any services the software depends on. Professional bodies such as BCS, The Chartered Institute for IT publish guidance on good practice in IT projects that is worth reviewing, and a solicitor should review any significant contract.

Red flags

• A price with no written scope behind it.
• Long lists of features described in one line each with no detail.
• No assumptions or exclusions at all, which usually means they have not been thought through.
• No acceptance criteria or testing phase.
• Most of the price due upfront.
• Code and hosting held only in the developer's accounts.
• Vague answers when you ask what happens if requirements change.

If you are replacing an existing system, the SOW needs extra detail on data migration and cut-over, which our guide to legacy system modernisation covers. For the full process, see our guide to custom web application development, and for WordPress-based projects, custom WordPress plugin development. For website projects rather than software, our guide to what a web design contract should include covers the equivalent document. You can see our work on our custom web apps, custom portals and custom CRM systems pages.

Frequently asked questions

Get a clear SOW

If you are comparing development proposals, ask us for a clear, itemised SOW. We write assumptions, exclusions and change control in plain English so you can compare us with anyone.