Statement of work template for software dev (2026)

You’ve agreed on the price. You’ve shaken hands. The agency says “we’ll start next Monday.” Three months later, the project is 6 weeks behind schedule, $22,000 over budget, and both sides are pointing fingers about what was “included” in the original agreement.

In 2026, this still happens on 60% of custom software projects [1]. Not because the developer is incompetent or the client is unreasonable. Because nobody wrote down — with surgical precision — what “the project” actually means.

That’s what a statement of work template for software development solves. Not a contract. Not a proposal. Not a “let’s get aligned” document. A statement of work is the legal definition of what gets built, what it costs, when it ships, and who owns the result. Every dispute on every project we’ve seen in 20 years traces back to something the SOW either didn’t cover or covered vaguely.

25-50%

PMI Pulse of the Profession, 2024

Statement of work template: the 8 sections that matter

Most SOW templates online are 2-page fill-in-the-blank forms. They cover project name, start date, end date, and total price. That’s a napkin agreement, not a statement of work.

A real SOW for software development has 8 sections. Skip any one of them and you’re creating a gap that scope creep, disputes, or cost overruns will fill.

Section 1: Scope of work

This is where projects live or die. The scope section lists every deliverable — not in vague terms (“user management system”) but in specific, testable terms (“user registration with email verification, login with password reset, role-based access control with 3 roles: admin, editor, viewer”).

The rule: if it’s not in the scope section, it doesn’t get built. No exceptions. No “well, obviously user registration includes social login.” If social login isn’t listed, it’s a change order.

We work with clients to define scope through product requirements documents before the SOW is written. The PRD captures everything the product should do. The SOW captures what gets built in this phase. The distinction matters — most products can’t be built in one phase, and the SOW must reflect that.

Section 2: Deliverables and acceptance criteria

Each deliverable needs three things:

Element	Bad example	Good example
What	”Dashboard"	"Admin dashboard showing daily active users, revenue (MRR), churn rate, and new signups — with date range filter (7d, 30d, 90d, custom)“
Done when	”Client approves"	"All 4 metrics display accurate data from production database. Date filter returns correct results. Page loads in under 2 seconds on 3G. Client signs acceptance form.”
Delivered as	”Source code"	"Deployed to staging environment, source code pushed to client’s GitHub repository, Figma designs transferred to client’s workspace”

The acceptance criteria column is the one most SOWs skip. Without it, “done” is a matter of opinion. With it, “done” is a checklist.

Section 3: Timeline and milestones

Don’t use a single delivery date. Break the project into milestones — typically 2-4 week blocks — each with its own deliverables and review period.

A sample milestone structure for a $45,000 MVP built over 12 weeks:

Milestone	Week	Deliverables	Payment
M0: Kickoff	0	SOW signed, project setup, access granted	20% ($9,000)
M1: Foundation	1-3	Auth system, database schema, CI/CD pipeline, staging environment	—
M2: Core features	4-7	[List specific features per project]	30% ($13,500)
M3: Integration	8-10	Third-party integrations, payment processing, email system	25% ($11,250)
M4: Launch	11-12	QA, performance optimization, production deployment, handoff	25% ($11,250)

Each milestone has a 3-day review window. The client tests the deliverables against the acceptance criteria. If they pass, the next phase begins. If they don’t, the developer fixes the gaps before moving forward.

This structure does two things: it forces regular check-ins (no “see you in 12 weeks”), and it ties payment to verified progress.

Section 4: The change order clause

This is the one clause that prevents scope creep. It’s also the clause most founders skip because they think it creates friction. It doesn’t. It creates clarity.

Every “small” feature request that bypasses this process costs $2,000-$8,000 and adds 1-3 weeks. We’ve seen projects with 15+ informal scope additions — none documented, none budgeted — that doubled the original cost. The founder felt cheated. The agency felt exploited. Both were right.

The change order clause isn’t bureaucracy. It’s the pressure valve that keeps both sides honest.

Section 5: Payment terms

Three payment structures exist. Each has trade-offs:

Fixed price — You pay a set amount for defined deliverables. Risk is on the developer: if it takes longer, they absorb the cost. Best when scope is locked and unlikely to change. This is what we use for most MVP development projects.

Time and materials (T&M) — You pay hourly or daily rates for actual work performed. Risk is on you: if it takes longer, you pay more. Best for ongoing development, R&D, or projects where scope will evolve. Requires trust and transparency.

Milestone-based hybrid — Fixed price per milestone, with the ability to re-scope future milestones as the project evolves. Best of both worlds for most projects. Each milestone is a mini-contract with defined deliverables and a fixed price, but you can adjust course between milestones.

Whichever structure you choose, the SOW must specify:

• Payment amounts and triggers (not “upon completion” — upon completion of what?)
• Invoice and payment timeline (Net 15? Net 30?)
• What happens if a payment is late (work pauses? interest accrues?)
• Refund conditions (what do you get back if you cancel after Milestone 2?)

Section 6: Intellectual property

Who owns the code? This question has ended relationships and started lawsuits.

The default in most jurisdictions: the developer owns what they create unless the contract says otherwise. If your SOW doesn’t include an IP assignment clause, you might be licensing your own product from the agency that built it.

Your SOW should state:

• All custom code, designs, and documentation transfer to you upon payment of the corresponding milestone
• Third-party libraries and open source components are licensed (not owned) — the SOW should list which ones
• The developer retains no rights to use, modify, or redistribute your custom code
• Pre-existing tools, frameworks, or boilerplate the developer brings to the project remain theirs (fair — they had these before your project)

Your NDA covers confidentiality. The SOW’s IP section covers ownership. These are different protections.

Section 7: Warranties and support

What happens after delivery? The SOW should define:

• Bug fix period: typically 30-90 days post-launch where the developer fixes bugs at no additional cost. Define “bug” precisely — a feature not working as specified in the acceptance criteria, not “I changed my mind about the design.”
• Support terms: response time for critical issues (hours, not days), availability (business hours or 24/7), communication channel (Slack, email, phone)
• Warranty exclusions: bugs caused by client modifications, third-party service outages, or changes to requirements after acceptance

For ongoing relationships, these terms evolve into a formal service level agreement. The SOW warranty is the bridge between “project complete” and “ongoing partnership.”

Section 8: Termination

Projects end early. Funding dries up. Priorities shift. The founder decides to pivot. The developer can’t deliver. The SOW must define what happens:

• Termination for convenience: either party can end the project with 15-30 days written notice. Client pays for work completed. Developer delivers all work product to date.
• Termination for cause: if either side breaches the SOW (missed milestones, missed payments), the other party can terminate with 7-14 days cure period.
• What you receive on termination: all source code, designs, documentation, and access credentials — regardless of how much has been paid. You paid for work completed; you should receive work completed.
• What you don’t receive: unfinished features, future development plans, or the developer’s internal project management data.

Statement of work vs scope of work: they’re not the same

People use these interchangeably. They shouldn’t.

A scope of work describes what gets done — the list of deliverables, the features, the boundaries. It’s one section of the larger document.

A statement of work is the entire agreement — scope, timeline, payment terms, IP ownership, acceptance criteria, termination clause. The scope of work lives inside the statement of work. Think of the scope as chapter 1; the SOW is the whole book.

Why this matters: if an agency sends you a “scope of work” and asks you to sign it, you’re missing 7 of the 8 sections above. You have a feature list with no payment protection, no IP clause, no change order process, and no termination terms. That’s not a contract. That’s a wish list.

Is a statement of work legally binding?

Yes — when it meets three conditions:

1. Both parties sign it. Verbal agreements and email confirmations are not SOWs.
2. It includes consideration. Payment terms in exchange for deliverables. This is what makes it a contract, not a project plan.
3. It’s specific enough to enforce. “Build a website” won’t hold up. “Build a 5-page marketing website with Stripe checkout, deployed to Cloudflare, delivered by March 15” will.

Most software agencies use a Master Services Agreement (MSA) as the legal umbrella — governing liability, jurisdiction, and dispute resolution — with the SOW attached as an exhibit defining the specific project. The MSA provides the legal framework. The SOW provides the operational detail. Together, they’re enforceable.

The SOW vs every other document

Document	Purpose	When you need it
NDA	Protects confidential information	Before sharing project details
Scope of work	Lists deliverables and boundaries	Part of the SOW (section 1)
SOW	Defines what gets built, who owns it, what it costs	Before any work begins
MSA	Legal framework (liability, jurisdiction)	Before signing the SOW
SLA	Performance guarantees post-launch	After the product is live
Change order	Amends the SOW for new requirements	During the project

Most agencies combine the MSA and SOW into one document. That’s fine — as long as all 8 sections above are covered.

The 3 SOW mistakes that cost founders money

Mistake 1: Vague deliverables. “E-commerce website” is not a deliverable. “Product catalog with filtering (category, price, size), shopping cart with quantity editing, Stripe checkout with Apple Pay and Google Pay, order confirmation email with tracking link” — that’s a deliverable. Define scope with the precision you’d use in user stories. Our project scope guide breaks down how to lock this before the SOW is written.

Mistake 2: Paying everything upfront. Any agency that demands 100% upfront is a red flag. Milestone payments align incentives: the developer earns payment by delivering working software, not by signing a contract. The standard is 15-25% upfront, with the remainder tied to milestones.

Mistake 3: No IP clause. You commissioned the work. You paid for it. But without explicit IP assignment language, the developer may own the copyright. This isn’t theoretical — it’s the legal default in the US, UK, and most of Europe for contractor (not employee) work.

---

The SOW is the document you’ll reference more than any other during a software project. It’s what you point to when the developer says “that’s out of scope” and what the developer points to when you say “I thought that was included.”

Make it specific. Make it mutual. And make sure the change order clause is in there — it’s the one paragraph that pays for the entire document.

If you’re ready to define your project scope, we start every engagement with a detailed SOW. No ambiguity. No surprises. Just a clear definition of what gets built.