What to include in a software development SOW

Most scope disputes don't happen because a client acted in bad faith — they happen because the SOW was vague about something both sides assumed was obvious, and it turned out they'd assumed different things. A strong SOW isn't longer for the sake of it; it's specific in the five places disputes actually originate. Skip one of these, and you're negotiating scope for free later, usually at the worst possible time — right before delivery, when the client's patience is thinnest and your margin is already spent.

Scope: be specific about what's out, not just in

"Responsive e-commerce website" describes almost nothing. A SOW that lists twelve features but never states that multi-currency support, multi-language content, or a native mobile app are explicitly out of scope leaves the client free to assume all three are included — because nothing said otherwise. The exclusions section is often the one paragraph that saves an entire change-request negotiation. Write it as plainly as the inclusions: "The following are not included in this scope: [list]. These can be added via a change request at the rates in Section 6."

Assumptions and dependencies

Every estimate rests on assumptions — that the client will supply brand assets by a certain date, that a third-party API will be available and documented, that content will be provided rather than written by you. State them explicitly, with the impact if they're not met: "If brand assets are not received by [date], the project timeline extends by the length of the delay." This turns a client-caused delay into a documented fact instead of an argument, and it's the single clause most likely to prevent a timeline dispute from becoming a relationship-damaging one.

Acceptance criteria per milestone

"Development complete" is not acceptance criteria — it's an opinion waiting to be disputed. Define what "done" means for each milestone in terms the client can verify without your help: specific user flows working, specific pages live, specific data migrated and spot-checked. Tie payment milestones to these criteria, not to calendar dates, so a delayed client-side dependency doesn't automatically trigger a payment obligation on your side for work that isn't actually verifiable yet.

Change request process

Scope will change — that's not a failure of planning, it's normal. What separates a healthy change from scope creep is whether there's a defined process: a written request, an estimate of added time and cost, and written approval before work starts. Without this in the SOW, every "can we just also add" conversation becomes a judgment call made under social pressure, one that usually resolves in the client's favor and your unpaid time.

IP, confidentiality, and support terms

State plainly when IP transfers to the client — typically on final payment, not on delivery — and what happens if the project is terminated early. Add a support and warranty window, 30 days of bug fixes post-launch is common, so "is this a bug or a new feature" doesn't become an open-ended free-support negotiation six months after go-live.

Tie the payment schedule to the SOW, not the calendar

A SOW that promises milestone-based payments but a separate invoice schedule tied to fixed dates creates a conflict the moment the project slips — which projects usually do, for reasons on both sides. If payment is contractually due on a date rather than on verified delivery of a milestone, you either invoice for work that isn't actually done, or you delay invoicing and absorb the cash flow gap yourself. Write the payment schedule directly into the same section as the acceptance criteria, so "paid" and "delivered and accepted" are always the same event, not two separate promises that can drift apart.

It's worth naming who signs off on acceptance, too. A SOW that says a milestone is accepted once "the client is satisfied" leaves room for one stakeholder to informally approve it in a call and a different one to reopen the argument weeks later. Name a single approver and a response window — five business days is common — after which the milestone is deemed accepted if no written objection is raised. That single clause resolves more late-stage payment disputes than any other line in the document.

A thorough SOW takes real time to write from scratch, which is exactly why it gets rushed under deadline pressure — and rushed SOWs are where the disputes above start. Dealora's contract generator drafts a full SOW, including exclusions, assumptions, and acceptance criteria, directly from the same brief used to build your proposal, so the document that protects you doesn't get cut for time.