TEMPLATE

Web Design Contract Template

A web design contract for freelancers and small studios covering pages, CMS, hosting access, browser support, launch, revisions, and who owns the code after final payment.

Updated

Start free in COLO

Not legal advice. Templates are provided as is, with no warranty — adapt yours and have a qualified professional in your jurisdiction review it before you rely on it. Terms of use

Article body

Most website projects that go wrong do not go wrong on design. They go wrong because the homepage copy arrives eight weeks late, the client's nephew still holds the domain login, or "can you just add a booking system" turns up two days before launch. A web design contract is where you decide, in advance and in writing, what happens in each of those moments.

This template is written for freelance web designers and small studios building marketing sites, portfolios, and small e-commerce stores on platforms like WordPress, Webflow, Shopify, or a custom stack. It assumes a fixed-fee build paid in milestones, with the code and design passing to the client once the last invoice clears.

TL;DR

The web design contract template covers the page and feature list, client content deadlines, browser and device support, hosting and domain access, milestone payments, revision rounds, launch sign-off, a 30-day bug-fix window, and IP transfer on final payment. Send it with the deposit invoice after the client accepts your proposal, and never start design work before both are back.

What's inside

  • Project scope — a sitemap table with page names, templates, and features, plus a "not included" list.
  • Platform and technical spec — CMS, hosting environment, supported browsers and screen sizes, performance and accessibility targets.
  • Client responsibilities — content, images, brand files, logins, and a named approver, each with a due date.
  • Timeline and content delays — the day-for-day slip rule and a pause clause for stalled projects.
  • Fees and milestones — deposit, design approval, development, and launch payments.
  • Revisions and change requests — rounds per phase and how out-of-scope features are priced.
  • Launch and acceptance — staging review, go-live, and the post-launch fix window.
  • Hosting, domains and third-party services — who owns which account and who pays for it.
  • Intellectual property — client ownership of the custom work, your retained components, third-party licenses.
  • Warranties, liability, termination, and governing law — the standard protective clauses with placeholders.

When to use it

Send this contract once the client has accepted a web design proposal and you know the page count and features. It works for new builds and redesigns up to roughly 30 pages.

Do not use it for ongoing care plans or monthly edits; those belong in a website maintenance SOW or a retainer agreement. For custom web applications with user accounts, APIs, and sprints, a software development agreement handles acceptance testing and source-code escrow better.

The template is jurisdiction-neutral: governing law, interest, and fee amounts are placeholders, so have a lawyer where you work review your filled-in version once before you rely on it.

Clauses web designers regret leaving out

Content deadline with a slip rule. The single most common cause of a delayed launch is missing copy. The contract should name the date content is due and say that every day of delay moves launch by a day. Some designers add a rebooking clause: if the project sits idle for 30 days, it goes back in the queue and a restart fee applies.

Browser and device support. "Works on everything" is unpriceable. Name the browsers (the last two versions of Chrome, Safari, Firefox, and Edge is typical) and the breakpoints you design for. Old browser versions and specific in-app browsers are out of scope unless listed.

Account ownership. Domain, hosting, Google Analytics, and paid plugins should be registered in the client's name with you as a collaborator. If you register them for convenience, say so and say when you transfer them. This avoids the awkward call two years later when the site is down and nobody can log in.

Third-party plugins and themes. Premium themes and plugins carry their own licenses and renewal fees. The contract should say the client pays for them and that you are not responsible for a vendor discontinuing a product.

Post-launch window. A defined window (14–30 days) for fixing genuine bugs at no charge, after which changes move to hourly or a maintenance plan. Without it, "one small thing" requests can continue indefinitely.

Customize it in your COLO workspace

Save this as a contract template in COLO Contracts, then fill it in per client. You can add your company signature, export a PDF, and send it to the client portal, where the client signs with a typed name or a signature image. The contract sits in the client portal next to the project files and invoices.

Set up the build as a project with tasks for design, development, and launch in project management, and raise the deposit and milestone invoices from invoicing and payments so the client can pay by card or PayPal from the portal.

Common mistakes

  1. Listing features without listing pages. A sitemap table is the clearest scope you can give. "A five-page website" invites a debate about whether the blog is one page or forty.
  2. Leaving SEO undefined. Say whether you are doing basic on-page setup (titles, meta descriptions, a sitemap) or nothing at all. Ranking outcomes should be explicitly excluded.
  3. Transferring the code before final payment. Keep the site on your staging environment until the last milestone clears, then move it live.
  4. Ignoring accessibility. Name the target (WCAG 2.2 AA is a common one) or state that an accessibility audit is out of scope. Silence leaves the question open.
  5. One contract for build and care plan. Separate them so the build can close cleanly.

FAQ

Q: What should a web design contract include?

At minimum the page list and features, revision rounds, a content deadline for the client, browser and device support, hosting and domain responsibilities, payment milestones, IP transfer on final payment, and what happens after launch.

Q: Who owns the website code after the project?

Usually the client owns the custom design and code once the final invoice is paid, while you keep your reusable components, starter themes, and snippets. Third-party themes and plugins stay under their own licenses.

Q: How do I stop a website project stalling on client content?

Put a content delivery date in the contract and a clause that moves the launch date day-for-day when content is late. Add a pause fee or a rebooking clause if the project is idle for more than 30 days. The website questionnaire helps you collect content needs up front.

Q: Should hosting and maintenance be in the same contract?

Keep the build and ongoing maintenance separate. The build contract ends at launch plus a short bug-fix window; maintenance belongs in its own retainer or maintenance SOW with a monthly fee.

Q: How many revisions should a web design contract allow?

Two rounds on the design mockups and one round on the built site is a common baseline. Define a round as one consolidated list of feedback so a stream of single-line emails does not count as unlimited revisions.

Frequently asked

What should a web design contract include?

At minimum the page list and features, revision rounds, a content deadline for the client, browser and device support, hosting and domain responsibilities, payment milestones, IP transfer on final payment, and what happens after launch.

Who owns the website code after the project?

Usually the client owns the custom design and code once the final invoice is paid, while you keep your reusable components, starter themes, and snippets. Third-party themes and plugins stay under their own licenses.

How do I stop a website project stalling on client content?

Put a content delivery date in the contract and a clause that moves the launch date day-for-day when content is late. Add a pause fee or a rebooking clause if the project is idle for more than 30 days.

Should hosting and maintenance be in the same contract?

Keep the build and ongoing maintenance separate. The build contract ends at launch plus a short bug-fix window; maintenance belongs in its own retainer or maintenance SOW with a monthly fee.

How many revisions should a web design contract allow?

Two rounds on the design mockups and one round on the built site is a common baseline. Define a round as one consolidated list of feedback so a stream of single-line emails does not count as unlimited revisions.

Stop rewriting the same document

The template is free to download. When you're ready, create your proposals, contracts and invoices in COLO, and your clients accept, sign and pay them in the client portal.

Start free in COLO Compare plans