Software development scope of work template for agency builds.

A software development scope of work is the document that states what you're building, how both sides will know it's finished, and what happens the first time someone asks for something that isn't in it. The version worth signing answers four questions that most templates leave open: what "done" means for each feature, what counts as a bug you fix for nothing, who pays when the client's own systems hold the work up, and what a change costs once code has been written. What follows is that wording, drafted against an internal operations tool for a logistics client at $64,000 across eleven weeks, so you can read the sentences instead of guessing at the brackets.

Those four matter more than everything else in the document because they're the only ones anybody ever fights about. Nobody disputes a confidentiality paragraph, and plenty of clients argue that the reporting screen was obviously meant to export to Excel, that a confusing dashboard counts as a defect, that six weeks of waiting on their IT team for database access was somehow the agency's schedule problem, and that a two-day change should be free because it's only two days.

What does a software development scope of work need to say?

Nine sections cover the whole job, and four of them carry the weight. The purpose section says why the software is being built and who uses it, in language the client's own team would recognize. The feature list describes what the software does, with acceptance criteria attached to every entry rather than collected in an appendix nobody reads. The technical section names the platforms, browsers and integrations you're supporting, and the phases give dates and tie each one to a payment. Then come the four that matter: the bug definition with its warranty window, the dependency section listing what the client owes you and what a slip costs, the change pricing for work that arrives after signature, and the acceptance rule. The handover and fee sections close the document out.

Compare that to what the popular software scope templates actually ship. One of the largest template libraries gives you organization details, a services description, deliverables, a schedule table, functional and non-functional requirements, assumptions, risks, a project team roster and a price table, then attaches a note to its own document saying the scope of work isn't binding and pointing you at a separate development agreement. There's no acceptance section anywhere in it, no definition of a bug, and no change-control paragraph. All the furniture is there, and the four clauses that decide who pays are the ones left to you.

How do you write a feature so both sides agree what "done" means?

Write every feature as a set of sentences someone can test in front of you and answer yes or no to, then add the line that says what the feature doesn't include. The usual failure is a feature list made of nouns. "User management" is a noun, and a noun can be stretched to mean anything from a login form to a permissions matrix with audit logging, which is exactly what happens in week seven when the client's operations lead sees the screen for the first time.

Here's the authentication entry from the $64,000 build, written the way it should read on the page.

1. A user registers with a work email address and receives a verification link that expires after 24 hours.
2. A password reset link arrives within five minutes and is single-use.
3. Two roles exist, administrator and standard, and an administrator can change any user's role.
4. A session stays signed in for 30 days across browser restarts.
5. This entry doesn't include single sign-on, two-factor authentication, or provisioning users from an external directory.

That last line does as much work as the four above it. Every feature in a software scope needs its own exclusion sentence, because the argument is almost never about what you built. It's about the neighboring thing the client assumed came attached to it. Single sign-on is the classic example: it sounds like a setting, it's usually a week, and nobody thinks to mention it until the client's security review asks about it. The same discipline is what makes any scope of work hard to misread, whatever the project type.

What counts as a bug, and what counts as a new feature?

A bug is behavior that contradicts something the scope already promised, and a change request is any behavior the scope never promised. That's the whole distinction, and writing those two sentences into the document is the highest-value ten minutes of drafting. Without them, "it's a bug" becomes a negotiating position rather than a description, and the agency ends up doing paid work for free because arguing about it feels worse than just fixing it.

The warranty window is the part agencies forget, and an open-ended one quietly turns into free support forever. Thirty days from acceptance of the final phase suits most agency builds, and the number matters far less than the fact that the clock starts on a date both sides can point at. Say what the window covers too, because a client who reads "warranty" without a definition will reasonably assume it includes the small improvements they've been saving up since week three.

A bug is the software breaking a promise the scope made. Everything else is a change request, however small it sounds.

Who pays when the client's own systems hold up the build?

The client pays, if the scope says so before it happens, and this is the clause that separates a software scope from every other kind. Design work stalls when the copy is late. Software work stalls when a client's IT department takes three weeks to approve a database connection, when the sandbox credentials for their payment provider never arrive, when the test data is a spreadsheet of made-up names that breaks on the first real import, and when the only person who can approve phase two is traveling.

So list those obligations by name, attach a date to each, and write the consequence in ordinary language. The version we'd use reads: where client-supplied credentials, environment access, test data or written approvals arrive more than five business days after the date shown in the schedule, remaining milestones move by the length of the delay, and developer time reserved for the affected phase is billed at $160 per hour until work can resume. It isn't a penalty and it shouldn't be presented as one. It exists so a six-week wait on someone else's IT queue doesn't quietly become the agency's overrun.

Third-party costs belong in the same section. Name which accounts the client pays for directly, whether that's cloud hosting, an email provider, error monitoring or an API with usage pricing, and say that usage charges during development are theirs. Agencies absorb a surprising amount of money here without noticing.

The fee structure sits underneath all of that. For most agency software work the answer that holds is both models in sequence: a paid discovery phase billed at a day rate whose only deliverable is the acceptance criteria, then a fixed price for the build those criteria define, which is how the $64,000 example ran, with $8,000 of discovery producing the feature list and $56,000 fixed against it. It's worth knowing that the big template libraries default the other way, to time and materials with a not-to-exceed cap invoiced monthly, because they were written for staffing a contractor inside someone else's team rather than for an agency selling a finished thing. The full comparison, including what a mid-project request costs under each model, is in time and materials vs fixed price.

How do you price a change once development has started?

Price it in tiers, and make written approval the gate rather than the formality. Anything under four hours goes at the stated hourly rate on a written approval. Anything above that gets a small written quote with a revised date attached. Anything that touches the data model or the architecture triggers a re-quote of the affected phase, because a change that sounds like one screen sometimes isn't. The $64,000 build used $160 per hour for the first tier and a fixed quote above it, with no code written before the approval comes back.

That last rule is the one agencies break, usually out of goodwill. Someone starts the change on Tuesday because it seems small and the client is nice, the approval never arrives, and by Friday there's a week of work nobody agreed to pay for. Every change wants its own written request, price, date and approval from the person the scope names, kept in one place rather than scattered across three email threads. A change request form does that on paper, and having the reply ready is most of what handling scope creep without losing the client comes down to.

What belongs in the handover at the end of a software project?

Name the artifacts, because "handover" on its own is a promise with no edge to it. On the logistics build the handover section listed repository ownership transferred to the client's own account, credentials for the staging and production environments, the deployment and rollback steps written down in the repository, every environment variable documented with what it does, and the third-party accounts moved into the client's name and billing.

Then say what the handover doesn't start. Hosting, uptime monitoring, response times, security patching and ongoing maintenance are separate agreements with their own fee, and a software scope that stays silent on them is read by most clients as including them. That assumption never surfaces as an argument, which is what makes it the most expensive one in this project type. It surfaces as a support request eight months later that you answer for free because invoicing twenty minutes feels petty, and then again the following month.

The five business days that decide who's right

If you add one clause to your next software scope, add the acceptance rule, because nothing above works without a moment where a phase stops being open. Written out for the logistics build it reads: each phase is submitted to the named client approver, who has five business days to accept it in writing or to list, in writing, the specific acceptance criteria not met; where neither arrives within five business days the phase is deemed accepted, the payment for it becomes due, and the 30-day defect window for that phase begins.

That single paragraph carries three numbers and a name, and it's what makes the bug definition, the warranty window and the change pricing mean anything at all, since each one starts counting from acceptance. Docket keeps that record without anyone maintaining it, which matters more on software than on other work because acceptance happens five or six times across a build rather than once at the end. The record won't settle a genuine legal fight and we don't sell it as though it would, but it answers the only question that comes up in practice, which is what was accepted, by whom, and on what date. If this is your first one, the website development scope of work covers the same ground for front-end builds, the difference between a scope of work and a statement of work is worth ten minutes before you pick a format, and what scope creep costs an agency makes the case for every clause above.

Frequently asked questions