What a software development statement of work should include

A software development statement of work (SOW) says what a partner will build, what you will receive, how finished work will be accepted and how changes will be handled. A good one is specific enough that two people reading it separately would agree on what 'done' means. Disputes on software projects often start with a section that was left vague.

This is practical guidance from the delivery side, not legal advice. Ask your own lawyer to review any contract before you sign it.

How a statement of work fits with the contract

Most partners use two documents. A master or service agreement holds the terms that apply to all the work, such as liability, confidentiality, IP and termination. The statement of work covers one piece of work: its scope, deliverables, timeline and price. When a new phase starts, you add a new SOW under the same agreement instead of renegotiating everything.

The sections every software SOW needs

1. Objectives

One short paragraph on the business problem and the result you want. When the detailed scope is unclear, this is what both sides check a decision against.

2. Scope and exclusions

Describe the scope as features or workflows, not as goals. 'Customers can reset their password by email' is scope. 'A modern user experience' is not. Then list what is out of scope. A clear exclusions list settles many arguments before they start, because it answers the question before anyone asks it.

3. Deliverables

Name everything you will receive: working software in named environments, source code in your repository, infrastructure definitions, deployment files, technical documentation and training. On Coretus projects, handover is part of the definition of done, not an extra. Whoever you work with, make sure the SOW treats it the same way.

4. Acceptance criteria

Acceptance criteria say how you will decide that a deliverable is finished, and each one should be testable. 'The invoice export matches the agreed column layout for a full month of invoices' can be tested. 'The export works correctly' can't. Also state who tests, how long the review period lasts, which defects block acceptance and what happens if nobody responds in time.

5. Milestones and timeline

Split the work into milestones, each with a clear output, a working demo and an approval step. That is how every milestone on our project delivery work is set up. Mark which milestones depend on input from your side, so a late decision moves the date openly rather than silently.

6. Assumptions and dependencies

Write down what the plan relies on. Typical examples are access to systems by a certain date, a product owner who can answer questions, content or data from your team, and third-party services that behave as documented. When an assumption turns out to be wrong, this section lets both sides adjust the plan fairly instead of arguing about blame.

7. Change process

Describe how a change is requested, assessed and approved, and how it affects the price and dates. A short process is better than a long one nobody follows. Our post on managing scope creep has a five-step version you can copy.

8. IP, confidentiality and data

The SOW, or the agreement above it, should say that you own the code, designs and other work created for you. At Coretus, clients own 100% of the code, designs and IP, and that is written into the service agreement. We sign an NDA before you share anything sensitive. Also cover how your data is handled and who can access which systems. For more on this, read protecting IP when outsourcing software development.

9. Payment terms

Tie payments to milestones you can check, such as an accepted deliverable, rather than to calendar dates alone. State what is fixed, what can vary and how approved changes are billed. If the work is a team on a monthly fee, say what the fee covers and how notice works when you add or remove people. The choice between a fixed price and paying for time used is covered in our post on fixed price vs time and materials.

10. Reporting, sign-off and support

Name the contacts on each side, how often you get updates and demos, and how problems are escalated. On our projects that means weekly updates, working demos, milestone reviews and a named owner for every decision. Then say what happens after launch: written sign-off, support while the release settles and an agreed period for fixing defects.

A checklist for reviewing a draft SOW

• Could someone outside the project tell from the scope what is and isn't included?
• Is every deliverable something you can see, run or open?
• Can each acceptance criterion be tested, and is there a set review period?
• Does each milestone have an output, an approval step and, where relevant, a payment?
• Are your own responsibilities and deadlines listed, not only the partner's?
• Is there a written change process that says how changes are priced?
• Does it state that you own the code, designs and IP?
• Is there a defect-fixing period after launch?

Common gaps in software SOWs

• No exclusions list, so every grey area becomes a negotiation.
• Acceptance by opinion, with wording such as 'to the client's satisfaction' instead of tests.
• Missing client responsibilities, so delays on your side have no agreed effect on the plan.
• Code without the rest: no deployment files, documentation or access handed over.

Where to start

Take your current draft, or the outline above, and fill in the exclusions and acceptance criteria first. They are the easiest sections to leave vague, and the ones you will rely on most if something goes wrong.

On our projects, deliverables, exclusions, dependencies, assumptions and approval criteria are agreed before work begins, and a scoped project can kick off in 1–2 weeks. If you'd like to talk through a scope you are preparing, book a free 30-minute call.