A software statement of work (SOW) is the written agreement that says exactly what a development team will build, how you will both know it is finished, what it costs, and what happens when the plan changes. A good one is specific enough that a stranger could read it and tell whether the work was delivered. A bad one is a page of adjectives. If you are hiring an agency, the SOW is the single document that protects your budget, your timeline, and the relationship.
This guide walks through what belongs in a software SOW, what to watch for, and how to read one before you sign. It is written for owners and operations leads at small and mid-sized businesses, not for lawyers. It is general guidance, not legal advice; have your attorney review any contract you sign.
Why the statement of work matters more than the proposal
A proposal is a sales document. It explains why you should pick an agency. A statement of work is an operating document. It explains what happens after you do. The two are often blended together, and that is where trouble starts: persuasive language such as "a modern, scalable platform" sounds like a promise but commits the agency to nothing you can check.
Most disputes in software projects trace back to the same gap: the buyer and the builder pictured different things and the paperwork never forced them to compare pictures. A clear SOW closes that gap before money is spent. It turns "I thought that was included" into a question you can answer by reading page three.
The core parts of a good software SOW
Every solid SOW covers the same ground, whatever the project. Use this list as a checklist when you review one.
- Background and goal. Two or three sentences on the business problem and the outcome you want, in plain English. This is the tiebreaker when a detail is unclear later.
- Scope of work. What is being built, listed feature by feature or workflow by workflow.
- Out of scope. What is explicitly not included. This is the most skipped and most valuable section.
- Deliverables. The tangible things you receive: working software, source code, documentation, admin accounts, training.
- Acceptance criteria. How each deliverable is judged complete.
- Timeline and milestones. Dates or durations tied to specific outputs, not vague phases.
- Pricing and payment schedule. The total or rate, and when each payment is due.
- Responsibilities. What you must provide, such as content, access, and decisions, and how fast.
- Change control. How new requests are priced and approved.
- Ownership, warranty, and support. Who owns the code, what is fixed for free afterwards, and what ongoing help costs.
Scope: say what is in, and just as clearly what is out
Scope is the heart of the document. A weak scope line reads "build a customer portal." A strong one reads more like this: customers log in with email and password, view their open orders, download invoices as PDF, and update their shipping address; staff see the same data plus an admin view to resolve tickets. Anyone reading that can picture the screens.
The out-of-scope list matters just as much. Typical entries include migrating historical data beyond a stated date, native mobile apps when the project is a web app, content writing, third-party licence fees, and integrations that are not named. Writing these down does not make the agency adversarial. It makes the price honest, because every unstated item is a future argument.
If your project involves connecting to other software, name each system. "Integrates with your accounting software" is an open door; "pushes paid invoices to QuickBooks Online through its official API" is a boundary. Integration work is one of the most common sources of surprise cost, which is why our solutions pages list typical budget ranges by project type and say what drives them up.
Deliverables and acceptance criteria: how you know it is done
A deliverable is a thing you can point to. "Design" is vague; "clickable mockups of the six screens listed in section 2, approved by you before development begins" is a deliverable. For each one, the SOW should say what format you receive it in and who signs off.
Acceptance criteria answer one question: what has to be true for you to say yes? Good criteria are observable. Examples:
- A staff member can create, edit, and cancel an order without developer help.
- The invoice PDF includes the line items, tax, and customer details shown in the approved mockup.
- The system works in the current versions of Chrome, Safari, Edge, and Firefox, and on a phone-sized screen.
- Known defects are fixed or listed with an agreed plan before the milestone is marked complete.
Also agree on the review window. A common pattern is a fixed number of business days to test and respond, after which the milestone is treated as accepted unless you report a defect. That protects the agency from silence and protects you from being rushed, as long as the number of days is realistic.
Timeline: milestones beat deadlines
A single end date tells you very little. Milestones tell you whether the project is healthy. A good SOW breaks the work into stages, such as discovery, design approval, first working version, testing, and launch, and ties each one to a deliverable and a rough date or duration.
Be honest about the dependencies that sit on your side. Timelines slip most often when the client is late with content, logins, or decisions. A fair SOW says so in both directions: the agency commits to delivery dates, and you commit to response times. If either side misses, the dates move by the same amount, and that rule is written down. For a look at how a project moves from kickoff to launch, see how we work.
Pricing: fixed price, time and materials, or a hybrid
The SOW should state the pricing model plainly, because each one shifts risk differently.
- Fixed price. One agreed amount for the defined scope. You get budget certainty; the trade-off is that the scope must be well defined and changes are priced separately.
- Time and materials. You pay for hours worked, usually with an estimate and a cap. It suits exploratory work, but without a cap or regular reporting the final cost is open-ended.
- Hybrid. A fixed price for a discovery or first phase, then a fixed or capped price for the next phase once the details are known. For uncertain projects this is often the most sensible structure.
Whatever the model, look for a payment schedule tied to milestones rather than dates alone. As of 2026, custom software at our shop typically falls in ranges such as $8,000 to $35,000 for a business website, $15,000 to $60,000 for system integrations, and $30,000 to $75,000 for internal tools, with the final figure driven by workflows, user roles, and integrations. Those ranges are why a one-line price with no scope behind it should make you cautious. You can see how we think about budgets on our pricing page.
Change control: plan for the change that will come
Projects change. You learn something halfway through, a regulation shifts, or a better idea appears. A good SOW does not pretend otherwise; it explains how change is handled. The usual process has four steps:
- You describe the change in writing.
- The agency responds with the effect on cost and timeline.
- You approve or decline the change in writing.
- Only then does the work begin, and the SOW is updated.
This process is a feature, not red tape. It keeps small favours from quietly growing into an overrun that nobody agreed to, and it gives you the choice to trade one feature for another to stay on budget. Beware of any SOW with no change process, because the first change will be negotiated under pressure.
Ownership, security, and support after launch
Many buyers read the scope carefully and skim the legal tail. Do not. Three items deserve a slow read.
- Ownership. Who owns the finished code and designs, and when does that transfer: on signing, or on final payment? You should also be told which third-party or open-source components are used.
- Access. Hosting, domain, repository, and admin accounts should be in your name or handed over at launch, so you are never locked out of your own system.
- Warranty and support. A defined period during which defects are fixed at no cost, what counts as a defect versus a new request, and what ongoing maintenance costs afterwards.
If the project handles customer data, the SOW should also state who is responsible for security measures, backups, and any compliance needs you have. Do not assume these are covered; ask for them to be named.
Red flags when reviewing a statement of work
- Scope written in marketing language with no features, screens, or workflows named.
- No out-of-scope list.
- "Unlimited revisions" or, at the opposite extreme, no revision rounds specified at all.
- Acceptance described as "to the client's satisfaction" with no measurable criteria.
- A single payment at the end, or most of the money up front with no milestones.
- No named responsibilities on your side, which usually means delays will be blamed on you later.
- The agency retains ownership of code you paid for, with no clear licence back to you.
A simple way to review your SOW before signing
Take a pen and read the document as if you were the person who has to run the software on a Monday morning after launch. For each section ask: could I tell whether this was delivered? If the answer is no, the language needs to be sharper. Then pick the three things you care about most, such as launch date, budget ceiling, and a specific integration, and find where each is written down. If you cannot find it, it is not in the contract.
You can also ask the agency to walk you through the SOW on a call. A confident team welcomes it. If the explanations are fuzzy, that tells you something about how the project itself will go. We have written up sample project types and how they were scoped in our case studies, and our custom software page describes what we typically build.
Frequently asked questions
How long should a software statement of work be?
Long enough to be unambiguous, short enough that you will read it. For small projects that is often three to eight pages. The length matters less than whether scope, deliverables, acceptance criteria, price, and change control are each written down specifically.
What is the difference between a SOW and a contract?
A contract, often called a master services agreement, covers the legal terms that apply across projects, such as liability, confidentiality, and payment terms. The SOW describes one specific project under that contract. Many small engagements combine both in a single document, which is fine as long as the project details are still clear.
Who writes the statement of work, the client or the agency?
Usually the agency drafts it after discovery conversations, and the client reviews, questions, and edits it. You can also bring your own requirements document to feed into it. Either way, nothing should be signed until both sides agree the scope reads the way they intended.
Can a statement of work change after it is signed?
Yes, through the change control process. A written change order that both sides approve amends the SOW. Verbal agreements and chat messages are not a substitute, because they are hard to point to when memories differ.
Should I ask for a fixed price or hourly billing?
If the scope is well defined, a fixed price gives you the most budget certainty. If the work is exploratory, a hybrid, with a fixed-price discovery phase followed by a priced build, is often safer than either extreme. The right choice depends on how much is still unknown.
Get a clear statement of work for your project
If you are planning a software project and want a scope you can actually check, contact Vadimages. We will talk through your goals, give you an honest range, and put it in writing in plain English, with what is in scope and what is not.