A website build looks simple on a sales call and gets complicated in week three, when the client asks whether the blog migration was included, which browsers you tested on, and who is meant to point the domain at the new server. A web development Statement of Work answers those questions in writing before you start, so the conversation in week three is a quick look at a table rather than an argument.
This template is written for web designers and developers building marketing sites, content sites and small e-commerce stores. It assumes the commercial terms already live in a contract, and it focuses on the technical scope: what gets built, where it runs, how it is tested and when it counts as done.
TL;DR
The web development SOW template lists every page template, the CMS and hosting stack, a browser and device support table, content responsibilities, a staging-to-production launch plan, acceptance testing and a post-launch fix window. Send the SOW with or right after the signed contract. The single most useful practice is a numbered page inventory, because unpriced extra pages cause more overruns than any other item.
What's inside
- Project overview — client, developer, site purpose, target launch date and the governing contract.
- Page and template inventory — a numbered table of every template and unique page, with notes on dynamic content.
- Technical stack — CMS or framework, hosting, domain, email and third-party services, plus who owns each account.
- Browser and device support — the exact versions and screen widths you test against.
- Content and asset responsibilities — who supplies copy, images and video, in what format, by when.
- Environments and launch plan — local, staging and production, DNS cutover steps and the launch window.
- Acceptance testing — the test checklist, how defects are reported and the sign-off window.
- Post-launch fix window — what the free period covers and when it ends.
- Fees, payment milestones and change requests — tied to build phases, not calendar dates.
When to use it
Use this SOW for any website build with more than a handful of pages, a CMS the client will edit, or a launch that involves moving a live domain. It is the right document when the client already accepted your web design proposal and you need the operational detail that a proposal leaves out.
It is not the same as the consulting Statement of Work, which is built around advisory phases, findings and recommendations rather than code, environments and browser testing. If you are building a custom web application with user accounts, an API and sprints, use the software development SOW instead, because its acceptance model is per user story rather than per page. And once the site is live, ongoing care belongs in a website maintenance SOW, not in an open-ended clause at the bottom of this one.
Scope items web developers forget to price
Most website overruns come from a short list of items that nobody wrote down.
Content migration. Moving 40 blog posts from an old CMS is real work: reformatting, re-uploading images, fixing internal links and setting redirects. Price it per post or as a fixed block, and state the source format you expect.
Redirects and SEO carry-over. If the client has an existing site with search traffic, mapping old URLs to new ones is a separate task. A typical small site has 30 to 150 URLs worth redirecting. List who builds the redirect map and who checks it after launch.
Forms and integrations. A contact form that sends an email is quick. A form that pushes data into a CRM, triggers a newsletter signup and validates a phone number is not. Name each form and each destination.
Third-party accounts. Hosting, domain registrar, analytics, email delivery and payment processors should be in the client's name with your access granted. The SOW should say so, because transferring accounts after launch is slow and occasionally impossible.
Accessibility level. If the client expects WCAG 2.2 AA conformance, that affects design, development and testing time. Write the target level into the SOW and say whether an audit is included.
How acceptance testing should work on a website
A clear acceptance process stops the project from sitting at "nearly done" for a month. Give the client a staging URL, a test checklist and a fixed window, usually 5 to 10 business days, to report defects in one consolidated list. Defects are measured against the page inventory and the support table, not against new preferences. Anything that is a change of mind rather than a bug goes through a change request. After the window closes with no open defects, the site is accepted and the launch milestone invoice is due.
Customize it in your COLO workspace
Once the client signs, set up the build as a project in COLO project management and turn each row of the page inventory into a task with a status and priority. You can mark which tasks the client can see in the client portal, share staging links and files there, and keep launch-week questions in the project chat.
If the build is fixed fee, set a project budget based on the hours you estimated. COLO warns you at 80% of the budget, and at 100% it stops billable timers and offers to request a contract update, continue as non-billable or pause, which gives you a clean moment to raise the extra pages the client added along the way.
Common mistakes
- Writing "approximately 10 pages". Approximate scope invites unlimited scope. Number every template and page.
- Leaving the launch plan blank. DNS changes, SSL setup and email records cause launch-day surprises. Decide in advance who does them and when.
- No content deadline. Without a date, missing copy becomes your delay. Add a clause that moves the launch date when content arrives late.
- An open-ended fix period. "We'll fix any issues" with no end date turns into free maintenance. Set the window in days.
- Skipping the support table. Without it, every device the client owns becomes in scope.
FAQ
Q: What should a web development SOW include?
At minimum a page and template inventory, the CMS and hosting setup, a browser and device support list, who supplies content, how acceptance testing works, launch responsibilities and a post-launch fix window. Each of those is a common source of disputes when left out.
Q: Who is responsible for content in a website build?
Usually the client, and the SOW should say so with a delivery date. If you are migrating or writing content, list it as its own line item with a page count, because content delays are the most common reason a launch slips.
Q: How long should the post-launch bug fix period be?
Many developers offer 14 to 30 days of free fixes for defects against the agreed spec. Make clear that the window covers bugs, not new features or design changes, which go through a change request.
Q: Do I need a separate SOW for website maintenance?
Yes. A build SOW ends at launch plus the fix window. Ongoing updates, backups and monitoring belong in a website maintenance SOW with its own monthly fee and response times.
Q: Should the SOW specify which browsers are supported?
Yes. A short support table, such as the last two versions of the major desktop browsers plus current iOS and Android browsers, turns "it looks broken on my old laptop" into a clear in-scope or out-of-scope answer.