A software project is a moving target. The client sees the first working screen and immediately has three new ideas, an API the app depends on changes its rate limits, and the definition of "finished" drifts with every demo. A software development Statement of Work does not stop any of that, but it gives you a fixed way to handle it: features are written as user stories with acceptance criteria, work happens in numbered sprints, and anything new goes into the backlog with a price before it goes into the build.
This template suits freelance developers and small teams building web apps, internal tools, mobile backends and integrations under a software development agreement.
TL;DR
The software development SOW template covers the product goal, a user-story backlog with acceptance criteria, a definition of done, development, staging and production environments, sprint milestones, demo and acceptance rules, a bug severity scale, repository and license details, and a warranty period. Send it before sprint one. The key practice is writing testable acceptance criteria for every story, because they decide when you get paid.
What's inside
- Product overview — the problem, the users and what release one must achieve.
- Backlog and acceptance criteria — user stories, priority and given-when-then criteria for each.
- Definition of done — the checks every story passes before it is demoed.
- Environments — development, staging and production, who hosts each and who can deploy.
- Sprints and milestones — sprint length, planned scope per sprint and the payment tied to each.
- Demo and acceptance — how the client reviews each sprint and the window to raise defects.
- Bug severity levels — critical to low, with response times during the build and warranty.
- Repository, licenses and handover — where the code lives, third-party licenses and documentation delivered.
- Change control — how new stories are estimated and swapped in.
When to use it
Use it for any build where the client will interact with working software along the way: an MVP, a customer portal, an internal dashboard, a mobile app's API. It assumes the legal terms are in a contract and handles only the delivery mechanics.
The consulting Statement of Work is designed for advisory phases ending in a report, so it has no concept of environments, sprints or bug severity. For a brochure website, the web development SOW is simpler and measures scope in pages rather than stories. If the requirements are still vague, sell a discovery phase SOW first and write this one from its output.
Acceptance criteria and environments in practice
Write criteria a stranger could test. "Users can reset their password" is a feature, not a criterion. Better: given a registered email, when the user requests a reset, then an email with a single-use link arrives within five minutes, the link expires after [N] hours and using it twice shows an error. Three to six criteria per story is a workable range.
Definition of done. A short, shared checklist applied to every story: code reviewed, automated tests passing, deployed to staging, criteria checked, no open critical or high bugs. It stops a story being "done" on your laptop and broken on staging.
Three environments, clear rules. Development is yours. Staging mirrors production and is where the client tests. Production is live. State who pays for each, whose cloud account it sits in, and who is allowed to deploy to production. Many developers deploy to production only on written approval after a sprint demo.
Data. Say whether staging uses real customer data, anonymized data or test data. Real data on staging is a common privacy problem.
Sprint acceptance. After each demo, the client has a fixed window, often 3 to 5 business days, to report defects against the criteria. After that, the sprint is accepted and its milestone invoice is due. New ideas raised in the demo go to the backlog, not into the current sprint.
Customize it in your COLO workspace
Create the build as a project in COLO project management and add each user story as a task with a priority, status and assignee. You can choose which tasks the client sees in the client portal, so they follow sprint progress without seeing internal chores, and use the project chat for demo follow-up.
Log time against each story with the timer. With a project budget set from your estimate, COLO warns you at 80% and stops billable timers at 100%, offering to request a contract update, continue as non-billable or pause. That turns an overrunning backlog into a priced conversation instead of silent unpaid work.
Common mistakes
- Criteria written after the build. If acceptance is defined at demo time, every demo becomes a negotiation.
- Production in your own cloud account. Moving it later is slow and risky. Start in the client's account.
- No severity scale. Without one, a typo on a settings page gets treated like a checkout outage.
- Swapping stories without swapping estimates. A new story can replace an old one only if its estimate fits.
- Open-ended warranty. "We'll fix bugs" with no end date becomes support you never priced.
FAQ
Q: What makes a software development SOW different from other SOWs?
Software scope changes as people use it, so the SOW needs acceptance criteria per feature, a definition of done, named environments, a bug severity scale and a clear rule for how new stories enter the backlog. Page counts and deliverable lists are not enough.
Q: Should a software SOW be fixed price or time and materials?
Fixed price works for well-specified, small builds. For anything with real uncertainty, many developers use time and materials with a capped estimate per sprint, or a fixed-fee discovery phase followed by priced sprints.
Q: How do I write acceptance criteria for a user story?
Use observable conditions, often in a given-when-then form: given a logged-in user, when they submit the form with a missing email, then they see an error and nothing is saved. If a tester cannot check it, it is not an acceptance criterion.
Q: Who owns the code at the end of the project?
That is set in the contract, but the SOW should state where the repository lives, that it is in the client's account, and which third-party and open-source licenses are used. Code ownership usually transfers on final payment.
Q: What warranty period is normal for custom software?
Many freelance developers offer 30 to 90 days of fixes for defects against the accepted criteria. New requirements, third-party API changes and issues caused by changes made by others are usually excluded.