Most guides to web design contracts are written by designers, for designers: how to protect your studio, how to write a style-release clause, how to word a late fee. This one is written for the other side of the desk, the client who has just received a contract from a designer and is trying to work out what to sign.
The clauses every web design contract should have
A complete web design contract covers ten things, at minimum:
- The parties: full legal names and contact information for both the client and the designer or studio
- Scope of work and deliverables: which pages, features, and files are included, and what counts as a change outside that scope
- Timeline and milestones: dates or phases the project is expected to hit
- Payment schedule: deposit amount, milestone or installment structure, and what triggers each payment
- Revisions and approval process: how many rounds are included and what happens once they're used
- Ownership, IP transfer, and usage rights: when the client's ownership of the design and code takes effect, and whether the designer keeps portfolio or usage rights
- Confidentiality: what either side can and can't disclose about the project or each other's business
- Termination conditions: the grounds for ending the contract early, and what each side owes if that happens
- Warranties, liability limits, and post-launch support: what the designer guarantees, what they're not liable for, and what happens after launch
- A place for both parties to sign and date
That list is the floor. The interesting part isn't whether a clause exists, it's who it's written to protect.
Who each clause actually protects
Three published contract guides make the asymmetry visible, because they quantify what they cover and, in doing so, show whose side they're drafted from.
HubSpot's Creating a Web Design Contract That Keeps Your Project on Track is the most detailed of the three, with fifteen sections. It reads as a template for the designer's protection. It recommends a style-release clause, which shields the designer from refund requests when a client dislikes subjective creative choices rather than a defined defect. It gives a worked late-fee example, "$20/day after 2-day grace period, max 14 days," charged to the client. It includes termination for non-payment or for "poor communication," grounds a designer can invoke against a client. The client gets no equivalent language to invoke against a designer. Liability is capped at the amount the client has already paid. That limits the designer's downside without saying what the client is owed if the designer walks away first. HubSpot even states who it expects trouble from: "Clients who push back on structured payments are often the ones who cause problems later." That sentence is written for the person drafting the contract, not the person signing it.
SPAL Web Solutions' What Should a Web Design Contract Include: Key Clauses Explained covers nine clauses and is the one exemplar of the three with an explicit tip addressed to the client. It puts the deposit at 30 to 50 percent upfront. It's also more specific on ownership: "full intellectual property rights transfer to the client upon receipt of final payment," stated as a plain trigger event rather than left implicit.
Slider Revolution's The Web Design Contract Guide is the clearest designer-side document of the three, and the tell is what it doesn't say. It lists sections (statement of work, client responsibilities, review and approval, timing, ownership, payment, confidentiality, cancellation) but quantifies none of them. There is no deposit percentage, no revision count, no cancellation fee. Instead of numbers, it points readers toward ready-made templates built by and for designers: Contract Killer, AIGA, Web Design Law, BidSketch, and RocketLawyer. Stuff and Nonsense's Contract Killer was first published in 2008 and is still sold as a template today. Its section list is public: cancellation, changes and revisions, communication, confidentiality, deliverables, portfolio display, intellectual property, non-exclusivity, payments, progressive enhancement, scope, and testing. The contract text itself isn't public, so a buyer can see the shape of the document without seeing the wording it uses.
Scoped to these three exemplars: two of them (HubSpot, Slider Revolution) are written from the designer's side, one (SPAL) includes something for the client, and none of the three publishes a client-side termination clause with the same specificity as its designer-side one.
The buyer's clause table: protective wording vs. the disqualifying version
The figures below come from the sources above and from our own sibling guides, restated here rather than re-derived. For the deposit and payment schedule, our guide to web design payment plans found, citing the Contra guide it audits, that most designers ask for 25 to 50 percent upfront, with 50 percent common on projects under $5,000. The same guide found the final payment is typically due before the completed files transfer or the site goes live, which leaves the client with no leverage after that point. For the revision definition, our guide to unlimited revisions in web design found that "two rounds included" without a definition of a round is functionally as unbounded as "unlimited," because neither states an end condition. For deliverables and handover, our website handover process guide audited two published handover checklists, thirteen items between them. None of the thirteen asks who is listed as the domain registrant. For ownership, our do I own my website guide found that ownership means three things together: the domain registered in your name, the source code, and the design files.
| Clause | Protective wording | Disqualifying wording |
|---|---|---|
| Scope and exclusions | Names the specific pages and features included and states what's explicitly excluded, so a change outside that list is visibly a change order | "Website design services" with no page count, no feature list, and nothing named as out of scope |
| Deposit and payment schedule | States a deposit as a percentage tied to a milestone, in the 25 to 50 percent range cited above, with each later payment tied to a specific deliverable | "Payment due in installments" with no percentages, no dates, and no deliverable attached to any payment |
| Revision definition | Defines what one revision round covers and what happens once the included rounds are used | "Revisions included" or a round count with no definition of what a round contains |
| Deliverables and handover | Names the specific files and accounts transferred at handover, including who is listed as the domain registrant | "Final files delivered upon completion" with no list of what "final files" means and no mention of the domain |
| Ownership and IP timing | States the trigger event for ownership transfer (typically final payment) and names all three components: domain, source code, and design files | "Client owns the final design" with no source files named, no domain mentioned, and no trigger event stated |
| Termination | States what each side owes if either one ends the project early, including whether the deposit is refundable and what happens to paid-for, unfinished work | Only the designer's exit terms are stated (non-payment, poor communication), with nothing addressing what the client keeps |
| Post-launch support | Names a specific support window and states what's covered (fixes to existing work) versus what counts as new, billable work | "Support available" with no window and no line between a fix and a new feature |
Source: HubSpot, SPAL, and Press's own guides to payment plans, revisions, handover, and ownership, cited above.
Termination: what the designer's exit looks like, and what to ask for as the client
Where the three exemplars are most consistent is termination, and it's consistent in one direction. HubSpot's contract permits the designer to terminate for non-payment or for "poor communication," and caps the designer's liability at whatever the client has already paid. Those are reasonable protections for a designer who has committed time to a project. They're also the only termination terms that appear in the three exemplars reviewed here. None of the three publishes an equivalent list of grounds the client can invoke. None states what the client is entitled to if the designer is the one who stops delivering.
That gap is worth raising directly with a designer before signing, as questions. The answer depends on the specific contract in front of you, not on any industry norm:
- If either side terminates before the project is finished, is the deposit refundable, in full or in part?
- If you've paid for work that isn't finished, who owns the drafts, files, and any code written so far?
- Does the contract state a timeframe for handing over paid-for, incomplete work, or does it leave that open-ended?
A contract that answers these three questions in writing, before you sign, is doing something the exemplars above don't do for the client's side of termination.
The on-the-record test
Here's a simple filter for reading any web design contract, published terms or a private draft. A vendor who publishes its terms can be held to them before you've paid anything. A vendor who only states terms in a private quote or a sales call can revise them in the room, and you have no earlier version to point back to.
As a worked example of what published terms look like, here's how Press answers several of the questions raised above. There's no deposit: we build the full site first and show it to you as a free preview before you've paid anything. If you keep it, the price is one flat payment of $299, published rather than quoted case by case, and it includes the source code. After that, revisions are free for ten days. All of this is stated on our own terms page, not held back for a sales call.
This isn't a claim that Press's terms are the right structure for every project. A five-figure e-commerce build has different scope and different risk than a single preview site. It's the point of the filter: whatever a designer's terms are, you can check them against what that designer has published. Treat a lack of anything published as its own answer.
Take it into the vetting conversation
Reading a contract is easier once you've already asked the designer these questions out loud. Our guide to questions to ask a web designer works through the same on-the-record test in more detail, including its finding that the agency-written vetting list it audited skips the deposit question. Raising the clauses above in conversation, before a contract lands in your inbox, is usually faster than negotiating them line by line afterward.
Questions
No. 01Do I need a lawyer to review a web design contract?
It depends on the size of the engagement. For a flat-fee project in the low hundreds of dollars, a lawyer's review is likely to cost more than what's at stake. For a five- or six-figure build, especially one with custom development or ongoing hosting, the review is small next to the cost of an unclear ownership or termination clause later.
No. 02What happens if there's no written contract at all?
Then none of the clauses above exist either: no defined scope, no payment schedule, no revision limit, no stated ownership trigger. Ask for a written contract before work starts. If a designer won't provide one, treat that itself as information about how the rest of the project is likely to go.
No. 03Can I negotiate the terms a designer sends me?
A draft contract is a starting point, not a final offer. The clauses most worth pushing on are the ones covered above: a defined revision round instead of an open-ended one, a stated trigger for ownership transfer, and termination language that says what happens to paid-for work if either side walks away.
No. 04What deposit is normal in a web design contract?
Most published schedules put the deposit somewhere between a quarter and half of the project price, with the higher end common on smaller projects. The deposit section above explains where those figures come from. What matters more than the percentage is what each later payment is tied to, and whether any of it is refundable if the project ends early.