Website development scope of work template, page by page.

A website development scope of work is the document you send before anyone opens a design file, and the version worth using names four things: how many page templates you're building, which screen sizes and browsers you're supporting, how many revision rounds the fee covers, and what the work outside that fee costs. Almost every template you can download today leaves all four blank and calls itself finished. What follows is the same document with the numbers already in it, written against a fourteen page marketing site rebuild at $38,500, so you can read the actual wording instead of guessing what belongs in the brackets.

The reason those four lines matter more than the rest is that they're the only ones anybody ever argues about. Nobody has ever disputed the confidentiality paragraph, and everybody disputes whether the careers page was one of the fourteen, whether Internet Explorer counted, whether the third round of homepage changes was included, and whether swapping the contact form for a booking tool was a small tweak or a new line item. Everything below is written to settle those four conversations before they start.

What goes into a website development scope of work?

Nine sections do the whole job, and you can write all of them in an afternoon. The project summary states what's being built and why, in three or four sentences the client would recognize as their own project. The deliverables section counts everything it can count, and the support section names the browsers and screen widths. The schedule gives dates and attaches the client's own obligations to them. The revision allowance states a number. The out-of-scope list prices the work you're not doing. The acceptance rule says how a deliverable stops being open. The change-control paragraph says what happens when something new comes up. The fee section splits the total across payment points.

Compare that to what the popular website scope templates actually ship. They give you a project overview, a task breakdown, a timeline with a start and end date, an intellectual property clause, a confidentiality clause and a termination clause, all of which are useful and none of which has ever prevented an argument about a fourteenth page. The legal furniture is the easy part, and it's the part every template gets right. The scoping is the part they leave to you.

What does a filled-in website scope of work look like?

Here's the deliverables section from the $38,500 rebuild, written the way it should read on the page. The project is a marketing site for a regional accounting firm, moving off an aging WordPress theme onto a custom build, with the client supplying all copy and photography.

1. Nine unique page templates: home, services index, service detail, about, team index, team detail, insights index, insights article, contact.
2. Fourteen pages built from those templates, listed by name in Appendix A.
3. One responsive treatment of each template at 375px, 768px and 1440px.
4. A content management setup covering the nine templates, plus a two hour training session recorded for the client's team.
5. Migration of 22 existing insights articles, with images, from the current site.

Notice what that list refuses to say. It doesn't say "responsive design", which is a promise with no edge to it, and instead names three specific widths. It doesn't say "content migration", which could mean 22 articles or 900, and instead says 22 and points at the appendix where the list lives. A client reading that section can tell you the exact moment it's been exceeded, and so can you, which is the entire purpose of writing it down.

How do you write website deliverables a client can count?

Turn every noun in the list into something with a number attached to it, and separate templates from pages. Agencies lose money on website projects mostly because the two get conflated: a client hears "fourteen pages" and assumes fourteen designs, while the agency priced nine templates filled fourteen times. Writing both numbers in the same sentence removes the ambiguity for the price of eight extra words. The same trick applies everywhere else in the document, and it's the same discipline behind writing a scope of work clients can't misread on any project type.

Browser and device support deserves its own line, because it's the one that surfaces at the worst possible moment. Name the browsers and the versions you're testing against, using a rule rather than a list that ages badly. Something like: current and previous major versions of Chrome, Safari, Firefox and Edge, plus Safari and Chrome on iOS at the stated widths. Everything else gets best effort without a fix guarantee. That sentence has ended more QA arguments than any clause we've written, because it converts "the site is broken" into "the site is broken in a browser we agreed not to test".

How many revision rounds should the scope include?

Two rounds on each design deliverable and one consolidated round after the build reaches staging covers most agency website projects, and the specific number matters far less than the fact that a number exists. An uncapped revision allowance isn't generous, it's just a fee you agreed to pay later. The version in the $38,500 example reads: two rounds of revision per template at design stage, one round of consolidated revisions at staging, with additional rounds quoted at $145 per hour before the work starts.

Define the round while you're at it, because the definition does as much work as the cap. A round is one set of consolidated feedback delivered in a single pass, not eleven emails arriving over nine days from four people who disagree with each other. Write that sentence into the scope and the client's internal review actually happens before the feedback arrives, which saves you more time than the cap itself ever will.

An uncapped revision allowance isn't generous. It's a fee you agreed to pay later.

What belongs on the out-of-scope list, and what should it cost?

Put the things clients most often assume are included, and put a number next to every one of them. On a website build that list is fairly predictable: copywriting, photography and art direction, page templates beyond the agreed count, ecommerce of any kind, additional language versions, third-party integrations not named in the deliverables, data migration beyond the stated article count, accessibility remediation to a named standard, and ongoing support once the warranty window closes.

The pricing is the part that changes the conversation. An unpriced exclusion is still an argument, because the client reads it as a door that might open for free. A priced one is a menu. When the accounting firm asks for a tenth template in week six, "that's out of scope" starts a negotiation, while "that's a tenth template at $2,400, want me to write it up?" ends in a yes or a no the same afternoon. Pricing the exclusions is also the cheapest insurance available against what scope creep costs an agency across a year of projects.

What happens when the client is late with the content?

Attach the client's obligations to the dates and say what a slip does to the schedule, because content delay is the single most common reason a website project runs long. The schedule section shouldn't only list your own milestones and deliverables. It should list theirs: final copy for all fourteen pages by a date, photography by a date, brand assets and logins by a date, and one named person with the authority to sign off on each stage.

Then write the consequence in plain language. The clause we'd use reads: where client materials arrive more than five business days after the date shown, remaining milestones move by the length of the delay, and any resulting work outside the original window is quoted before it starts. That isn't a penalty and it shouldn't be framed as one. It just stops a three week content delay from silently becoming a three week overrun that everybody blames on the agency.

Is a website development scope of work legally binding?

It depends on how the document was issued, and the free templates you're most likely to download will give you two opposite answers. One of the biggest template libraries states plainly that a signed website scope of work is a legally binding document. Another attaches a note to its own template saying it isn't legally binding and pointing you toward a separate service agreement. Both are describing real situations, and neither one explains which situation you're in.

The distinction is what the document is standing on. A scope of work that both parties sign, carrying a fee, a payment schedule and terms of its own, is generally treated as an agreement in ordinary US business practice. A scope of work issued under an existing services agreement is normally read together with that agreement, which is where the payment and liability terms actually live. Either arrangement works for agency projects, and the useful step is knowing which one you're using and cross-linking the two documents by name. If you're deciding between them, the difference between a scope of work and a statement of work is worth reading first. We build software for agencies rather than practicing law, so have a lawyer read your standard template once and then reuse it with confidence.

The line that separates templates from pages

If you add only one sentence to your next website scope, add the one that splits the template count from the page count, because that's the ambiguity this project type is built on. Written out for the accounting firm rebuild it reads: nine unique page templates, deployed across the fourteen named pages listed in Appendix A, with each additional unique template quoted at $2,400 and each additional page built from an existing template quoted at $600. That's one sentence carrying three numbers, and it takes away the ground the two most expensive website arguments usually stand on.

Whatever else you change, the document only holds if changes to it get recorded the way the original was. Every approved change wants its own written request, its own price, its own date and its own approval from the person the scope names, kept together rather than spread across four email threads and a phone call nobody wrote up. A change request form does that on paper, and if you'd rather start from a general document than a website-specific one, the project scope document template covers the same ground for any project type.

Frequently asked questions