Reviewed by Zohaib KhalidCEO & Co-founder, Innovation Insight·Updated Short answer
A statement of work (SOW) for software development defines what will be delivered, how each deliverable is accepted, when it is due, what it costs and what happens when scope changes. This template has fifteen sections, from parties and background through a deliverables table, acceptance process, milestones, fees, change control, IP ownership, confidentiality, warranty and termination, to signatures. It works for fixed-price and time-and-materials contracts and sits under a master services agreement or on its own.
How to use this statement of work template for software development
A statement of work turns a proposal into commitments: this deliverable, accepted this way, by this date, for this fee. Fill in the deliverables table first, because everything else refers back to it. Then write the acceptance criteria for each row. If you cannot say how a deliverable will be accepted, it is not defined well enough to sign for. The rest of the document (fees, change control, IP, warranty) is mostly standard wording you adjust once and reuse.
Attach the SOW to a master services agreement if you have one and let the MSA carry the legal boilerplate (liability, insurance, dispute resolution). If there is no MSA, the sections on IP, confidentiality and termination below are enough for most projects under a few hundred thousand dollars, but have a lawyer check the governing-law and liability wording for your jurisdiction.
SOW template vs scope of work template
People use the two names for the same document, and it rarely matters. Strictly, a scope of work is the section that lists what is being built, and a statement of work is the whole contract-ready document that wraps it with schedule, fees and terms. This template is the full statement of work; section 3 is the scope of work. If a vendor sends you only a scope, ask for the rest.
What makes a software SOW hold up
- Deliverables that are things, not activities. "Admin dashboard with the six reports in Appendix A" can be accepted; "dashboard development" cannot.
- An acceptance process with a clock. Five business days to test, written list of defects, deemed accepted if silent. Without the clock, projects end in a long tail of unpaid invoices.
- Milestones tied to payments, so neither side carries all the risk.
- The contract type stated plainly. Fixed price needs a frozen scope and a change-request path; time and materials needs a rate card, a cap or a monthly estimate and a notice period. Our engagement models page explains when each fits, and fixed price vs time and materials goes deeper.
- Client responsibilities written down. Late content, slow approvals and missing API credentials are the usual causes of delay, and the SOW should say what happens to the schedule when they occur.
- IP assignment on payment and a licence back for the vendor's pre-existing tools, so there is no argument about who owns what.
How we write our own SOWs
Every Innovation Insight engagement starts with a signed SOW that follows this structure. The deliverables table is written with the client during the discovery phase and reviewed line by line on a call before signing. Acceptance is five business days per milestone with a written defect list, and we deploy to your accounts so hand-over is never a separate event. IP transfers to you when each milestone is paid, as our security page describes. The sections below are the ones we use, with the project-specific wording left blank.
Free download
Get the Statement of Work Template for Software Development
Markdown that opens anywhere (Google Docs, Notion, GitHub, your AI coding tool) or a Word file. Tell us where to send it and a senior engineer will answer any question you add.
Just want the file? Download Markdown without the form or the Word version.
The template
Every section below is in the download. Replace each blank line with your own text and delete the guidance paragraph once you have written the section.
1. Parties and effective date
Full legal names and registered addresses of both parties, the date the SOW takes effect, and the master agreement it sits under, if any.
- Client legal name and address: ____
- Vendor legal name and address: ____
- Effective date: ____
- Governing master services agreement (title and date), or "none, this SOW stands alone": ____
- SOW number or reference: ____
2. Background
Two or three sentences on why the project exists and what the business is trying to achieve. It gives the rest of the document context when someone reads it in a dispute two years later.
- Business context: ____
- Project objective in one sentence: ____
- Related documents (proposal, RFP, PRD) incorporated by reference: ____
3. Scope of work and deliverables
The heart of the SOW. List each deliverable as a thing that can be handed over and tested, with a short description and a reference to the fuller specification. Activities such as "design" or "testing" belong in the description of a deliverable, not as rows of their own.
- Summary of the work in one paragraph: ____
- Specification documents attached as appendices: ____
- Environments to be delivered (development, staging, production) and who owns them: ____
| # | Deliverable | Description and specification reference | Acceptance criteria | Due |
|---|---|---|---|---|
| D1 | ____ | ____ | ____ | ____ |
| D2 | ____ | ____ | ____ | ____ |
| D3 | ____ | ____ | ____ | ____ |
| D4 | Source code and documentation | Repository in the client's account; README, deployment runbook, architecture notes | Repository transferred; runbook followed by client engineer to deploy successfully | Final milestone |
4. Out of scope
List what the parties discussed and excluded. Anything on this list that later becomes necessary goes through change control rather than being argued about.
- Excluded: ____
- Excluded: ____
- Excluded: ____
- Third-party costs not included in the fees (hosting, licences, app store fees, SMS, AI tokens): ____
5. Acceptance criteria and process
State how each deliverable moves from delivered to accepted, with a review period and a rule for silence. Defects should be classified so a cosmetic issue cannot block a milestone payment.
- Review period after delivery notice: ____ business days
- Defect classes: critical (blocks core use), major (workaround exists), minor (cosmetic). Only critical and major defects delay acceptance.
- Client provides defects in writing in the agreed tracker; vendor fixes and redelivers; review period restarts for the fixed items only.
- Deemed acceptance: a deliverable is accepted if no written defect list is received within the review period, or when used in production.
- Acceptance authority (name, role): ____
6. Milestones and schedule
Dates or durations for each milestone, which deliverables each one contains, and the assumption about the start date. Make it clear that client delays move the dates.
- Planned start date: ____
- Milestone 1: ____ | deliverables: ____ | due: ____
- Milestone 2: ____ | deliverables: ____ | due: ____
- Milestone 3: ____ | deliverables: ____ | due: ____
- Final delivery and hand-over: ____
- Schedule adjusts day for day for delays caused by late client inputs, approvals or access listed in section 7.
7. Team and responsibilities
Name the people on both sides and what each side must provide. Most delays trace back to a missing client input, so be specific about turnaround times for reviews and credentials.
- Vendor team (name, role, allocation): ____
- Vendor project lead and escalation contact: ____
- Client product owner with authority to accept and prioritise: ____
- Client technical contact: ____
- Client provides within ____ business days of request: access to systems and APIs, content, brand assets, test data, decisions on open questions.
- Meetings: weekly demo and planning, daily written stand-up, monthly steering review.
- Tools: repository, tracker, chat and document store to be used: ____
8. Fees and payment schedule
Choose one contract type and delete the other wording. Fixed price: a fee per milestone, invoiced on acceptance. Time and materials: a rate card, a monthly estimate or cap, and the rule for exceeding it. State currency, payment terms and what happens on late payment.
- Contract type: [ ] fixed price [ ] time and materials [ ] dedicated team (monthly)
- Fixed price wording: the total fee is $____, payable as ____ percent on signature, then on acceptance of each milestone as set out below. The fee covers the deliverables in section 3 and no other work.
- Time and materials wording: work is billed monthly at the rates below for hours actually worked, with a monthly estimate of ____ hours. The vendor will not exceed the estimate by more than ____ percent without written approval.
- Rate card (role, hourly or monthly rate): ____
- Milestone payment table: M1 $____ | M2 $____ | M3 $____ | final $____
- Currency and payment terms: ____, net ____ days from invoice
- Expenses and third-party costs: passed through at cost with prior approval
- Late payment: work may pause after ____ days overdue; schedule extends accordingly
9. Change control
A short written process for changing scope, schedule or fee. Either side can raise a change request; nothing changes until both sign it. Small changes can be absorbed by agreement, but write down the threshold.
- Either party may request a change in writing describing the change, its reason and the requested timing.
- The vendor responds within ____ business days with the effect on scope, schedule and fees.
- No change is effective until approved in writing by both parties' named authorities.
- Changes under ____ hours may be absorbed within the current milestone by mutual agreement and logged.
- Change log location: ____
10. Assumptions and dependencies
Everything the price and schedule depend on. If an assumption fails, the parties use change control rather than a dispute.
- Technical assumptions (stack, environments, third-party availability): ____
- Client-provided items and the dates they are needed: ____
- Third-party dependencies (APIs, app store review, payment provider approval): ____
- Volume assumptions (users, data, transactions) used for sizing: ____
11. IP ownership and licences
Who owns the delivered work, when ownership passes, and what the vendor keeps. The usual split: the client owns everything built for them on payment; the vendor keeps its pre-existing tools and grants a perpetual licence to use them within the delivered product; open-source licences are respected.
- All deliverables created under this SOW are assigned to the client on payment of the corresponding milestone.
- Vendor pre-existing materials (list): ____, licensed to the client perpetually and royalty-free as part of the deliverables.
- Open-source components are used under their own licences; a list is provided with the final delivery.
- The vendor may describe the project in general terms as a reference: [ ] yes [ ] only with written approval [ ] no
12. Confidentiality
Refer to the NDA if one is signed; otherwise include a short mutual clause. Cover data handling for anything personal or regulated.
- Confidentiality is governed by the mutual NDA dated ____, incorporated by reference. (Or: insert mutual confidentiality clause.)
- Personal or regulated data in scope: [ ] none [ ] personal data (GDPR) [ ] health data (HIPAA) [ ] card data (PCI DSS)
- Data processing agreement or business associate agreement attached: ____
- Access to client systems is granted per project, with MFA, and revoked at completion.
13. Warranty and support period
A defect warranty after final acceptance, usually 30 to 90 days, covering bugs in delivered work at no charge. Separate it clearly from ongoing support, which is a retainer under its own terms.
- Warranty period: ____ days from final acceptance, covering defects in the deliverables against the agreed specification.
- Excluded from warranty: changes made by others, third-party service changes, new features, environment changes outside the vendor's control.
- Response time for warranty defects: critical within ____ hours, others within ____ business days.
- Post-warranty support: available under a separate support agreement (or SOW) at ____.
14. Termination
How either side exits, with notice, and what is paid and handed over on exit. For time and materials, a notice period is enough; for fixed price, pay for accepted milestones plus work in progress at the day rate.
- Either party may terminate for convenience with ____ days' written notice.
- Either party may terminate for material breach not cured within ____ days of written notice.
- On termination the client pays for accepted milestones and work in progress to the termination date; the vendor hands over all work product, credentials and documentation within ____ business days.
- Sections 11, 12 and 13 survive termination.
15. Signatures
Signed by someone with authority on each side. Countersigned electronic signatures are fine.
- For the client: name ____ | title ____ | signature ____ | date ____
- For the vendor: name ____ | title ____ | signature ____ | date ____
- Appendices: A specification, B rate card, C change request form, D NDA or DPA
Filled it in?
Send us the document and get a written estimate.
A senior engineer replies within one business day with the assumptions we would make and a range per milestone.
Zohaib Khalid
CEO & Co-founder, Innovation Insight
Zohaib leads strategy, client partnerships and delivery at Innovation Insight. He has spent a decade turning founder briefs into products that ship and still reviews every proposal that leaves the company.
LinkedIn