What should a web design contract include?
A web design contract should include ten things: scope and deliverables, ownership of design and code, revision rounds, a change-order process, payment terms, timeline and dependencies, cancellation and kill fees, handover, post-launch support, and confidentiality. If any of these are missing, you're relying on goodwill rather than the document.
Most website design contract guides are written for freelancers protecting themselves from clients. This one is written from the buyer's side, for a founder or marketing lead about to sign with a studio or agency. The goal isn't to win an argument with your agency. It's to make sure that when something changes, as it always does on a website project, both sides already know what happens next.
We're a studio, not a law firm, so treat this as a practical checklist and have a lawyer review anything high-stakes. The table below is the short version. Each section after it explains one clause, what good looks like, and links to a deeper guide.
Clause | What good looks like | Red flag |
|---|---|---|
Scope and deliverables | Pages, templates, features and copy listed | A single line like full website design |
Ownership (IP) | Transfers to you on final payment | Agency keeps code or licenses it to you |
Revisions | Defined rounds per phase, with a process | Unlimited, or not mentioned at all |
Change orders | Written, priced and approved before work | Extra work billed after the fact |
Payments | Milestones tied to deliverables | Most of the fee due before any work |
Cancellation | Pay for work done plus a fair fee | Full fee owed whenever you cancel |
Handover | Files, repo, CMS and accounts listed | The site is yours, with no list |
Support | Defined warranty window for defects | No support, or vague ongoing help |
Who owns the website design and code after the project?
You should own the final website design, code and content once you've paid in full, and the contract should say so in plain words. Without an explicit transfer, ownership can stay with the agency by default, which can leave you licensing your own site.
Ownership clauses usually split into three parts. First, the deliverables made for you, such as page designs, custom code and written copy, which should transfer to you on final payment. Second, the agency's pre-existing tools, like internal components or starter code, which they keep but should license to you permanently for your site. Third, third-party assets like fonts, stock images and plugins, which come with their own licenses that you should hold in your name.
The exact words matter more than people expect. Look for language that assigns rights on full payment, not just a promise to deliver files. Our guide to who owns the website design and code includes the transfer wording to ask for and what to do if a contract is silent.
How should the scope and deliverables be written?
The scope should list every page, template, feature, integration and piece of copy the agency will deliver, plus what's explicitly out of scope. A specific scope is the single clause that prevents most disputes, because revisions, payments and change orders all depend on it.
A good scope section reads like a checklist you could tick off at launch. It names the pages or templates, the CMS collections, the forms and integrations, the responsive breakpoints, the animation level, who writes the copy, and which browsers are supported. It also names what's excluded, such as migration of old blog posts, ongoing SEO, or paid stock imagery.
- Pages and templates. A blog with 200 posts is usually one template plus an import, not 200 pages.
- Copy. Say whether the agency writes it, edits yours, or uses placeholder text.
- Integrations. Name each one: CRM, analytics, booking, newsletter.
- Assumptions. List what you'll provide and by when, like brand files or product screenshots.
If you haven't written a brief yet, start with our web design brief template, then compare the agency's scope against it line by line. When scope changes mid-project, the contract's change-order clause takes over, which we cover in how to prevent scope creep in web design.
How many revision rounds should a web design contract allow?
A web design contract should name a specific number of revision rounds for each phase, define what counts as a round, and say what happens after the last one. The number matters less than the structure: two well-run rounds produce better work than six scattered ones.
A revision round should mean one consolidated set of feedback from your side, delivered in one place, followed by one revised version from the agency. When feedback trickles in from five people over two weeks, every message becomes its own round, and the project stalls. A good contract asks you to name one decision maker and to send feedback together.
Watch for two extremes. Unlimited revisions sounds generous, but it usually means no one is accountable for reaching a decision, and it can hide slow delivery. No revisions mentioned at all leaves you arguing later about what's reasonable. Also check whether changing direction counts as a revision or as new scope; a new layout concept after approval is normally a change order, not a round.
We explain how to structure rounds by phase, and why fewer often works better, in our guide to design revision rounds.
What payment terms are fair in a web design contract?
Fair web design payment terms tie each payment to a visible deliverable: a deposit to start, one or more milestones for approved design and build, and a final payment at launch or handover. You should never pay most of the fee before seeing meaningful work.
Common structures include a split between start and launch, payment in thirds across design, build and launch, and monthly billing in advance for retainers. Each has trade-offs. A deposit protects the agency's reserved time. Milestones protect you, because payment follows progress. Net-30 terms on invoices help your cash flow, but some smaller studios can't carry that much unpaid work and will price it in.
Check three details beyond the percentages. When does a milestone count as reached: on delivery or on your approval? What happens if you take weeks to approve? And are late fees or work pauses defined? Our guide to web design payment terms compares the structures and what each one signals about the agency.
Hypothetical example: a milestone schedule that protects both sides
Hypothetical example: a studio quotes a fixed fee for a six-page website. The contract splits payment into a deposit to reserve the slot, a payment when you approve the final designs, and a final payment at launch. It also says that if you don't respond to a milestone delivery within ten business days, the milestone counts as approved for billing, and the schedule moves by the length of the delay.
The agency gets paid for work it has done even if you get busy. You get the assurance that most of the money only moves once you've seen and approved the work. The numbers here are illustrative; the structure is the point.
What happens if you need to cancel the project?
If you cancel, a fair contract says you pay for work completed to date plus a defined kill fee, and you receive the files for what you've paid for. The kill fee compensates the agency for reserved time it can't resell at short notice, not for work it never did.
Look for a termination clause that works both ways. You should be able to end the contract with written notice, and the agency should be able to end it if you stop paying or stop responding. The clause should say exactly what's owed at each stage and when files transfer. A contract where the full project fee is owed regardless of when you cancel is one-sided.
Projects get cancelled for ordinary reasons: a funding round slips, a product pivots, a new executive wants a different direction. The contract shouldn't punish that, but it shouldn't leave the studio carrying the cost either. We cover fair structures and what to negotiate in design contract kill fees and cancellation terms.
What should handover and post-launch support cover?
Handover should list every file, repository, CMS login, domain and third-party account you'll receive, and post-launch support should define a warranty window in which the agency fixes defects at no charge. Without both, launch day can quietly become the day you lose access to your own site.
A handover clause is easiest to judge as a list. Design source files, the code repository with full history, admin access to the CMS and hosting, the domain registrar and DNS, analytics, form and email integrations, and font and image licenses. Each account should be in your company's name, with the agency added as a user, not the other way round.
The warranty clause should separate defects from new work. A broken form, a layout bug on a supported browser or a page that doesn't match approved designs is a defect. A new section, a changed headline or a new integration is new work. Our guide to the website warranty period explains a fair window and when ongoing support should become a retainer.
How is a retainer agreement different from a project contract?
A retainer agreement covers an ongoing monthly relationship rather than one defined deliverable, so it focuses on capacity, priorities, notice periods and minimum commitments instead of a fixed scope. The ownership, confidentiality and handover clauses still apply, month by month.
The clauses to read hardest in a retainer are the commitment and the notice period. Some retainers require a long minimum, such as a 12-month commitment, which gives the agency stability but leaves you paying for capacity you may not need. Month-to-month terms with a short notice period put more pressure on the agency to keep delivering, which is usually better for the buyer.
A retainer should also say how work is requested and prioritized, what a typical month can include, whether unused capacity rolls over, and how either side ends it. We go through each term in our design retainer agreement checklist. If you're still choosing between models, our guide to a full-service web design agency explains when one team for words, design and code makes sense.
Which contract red flags mean you shouldn't sign?
Walk away, or push back hard, if the contract leaves the agency owning your code, describes scope in one vague line, makes the full fee due on cancellation, or has no handover list. These clauses tell you how the agency expects disagreements to end.
- Ownership stays with the agency or is only licensed to you while you keep paying a fee.
- Scope is a sentence, like custom website design, with no list of pages or features.
- Most of the fee is due before design starts, with nothing tied to approvals.
- Changes are billed hourly with no written approval step.
- Hosting or the domain is in the agency's name with no transfer clause.
- No warranty or support window is defined at all.
One red flag isn't always a deal breaker; agencies often accept reasonable edits when you ask. The bigger signal is how they react. A studio that explains its clauses and adjusts them for a fair reason is one you can work with. A studio that refuses to discuss ownership or cancellation is telling you something. Our guide to the best web design agency for startups covers the other signs to check before you sign.
Should you use a web design contract template?
A web design contract template is a useful starting point for comparing agencies, but don't sign a generic one unchanged. Templates miss the specifics that matter: your pages, your integrations, who writes copy, and what's handed over.
Use a template as a checklist. When an agency sends its own contract, which most do, compare it clause by clause against the list at the top of this guide and the deeper guides below. Ask for changes in writing and keep the redlined version. If the project is large, includes sensitive data, or involves international parties, have a lawyer review it; the American Bar Association's lawyer referral resources at americanbar.org are one place to start in the US.
If you want to check… | Read next |
|---|---|
Who owns the design, code and content | |
How many revisions to expect | |
Deposits, milestones and net-30 | |
Change orders and budget control | |
Monthly retainer terms | |
Cancellation and kill fees | |
Support after launch |
And if you're at the stage of comparing proposals rather than contracts, our web design proposal template shows what a complete proposal should spell out before a contract is even drafted.
