What to Include in a Web Design Contract: Clauses to Check Before Signing
The document you sign before a website project starts decides who owns what when the project ends. In this guide we walk through the clauses to look for when you draft or review a web design contract, along with the gaps we see most often in the field. Note: this article is not legal advice, so please ask a lawyer to review any contract before you sign it.
What is a web design contract and why should you read it before signing?
A web design contract is a written agreement between a business and a design team that sets out scope, delivery schedule, payment milestones, intellectual property, account ownership, warranty period and termination terms. Its purpose is to align both sides before work begins and to prevent disputes later.
In practice, projects that start on a handshake usually run into trouble after launch. For example, the owner assumes the domain belongs to the business, while the registration actually sits in the agency account. Or the team thinks it offered three rounds of revisions, while the client expects unlimited changes. So we suggest you read the draft line by line.
A contract is also more than a safety net. In practice, it works as the project roadmap, because it tells everyone who delivers what and when. We start every project in our web design service by going through these clauses one by one with the client.
How do a brief, a proposal and a contract differ?
People often mix up these three documents, yet each one has a different job. The brief describes what you want. Next, the proposal describes the solution and price the team offers in response. The contract then turns both into a binding agreement. Therefore, the contract should either attach the proposal scope or refer to it clearly.
We cover brief writing in our guide on how to write a website design brief, and comparing offers in how to evaluate a web design proposal. Here, then, we focus only on the contract itself.
| Document | Who prepares it? | What does it cover? | Binding? |
|---|---|---|---|
| Brief | The business | Goals, audience, reference sites, content status | No, it is an input |
| Proposal | The design team | Suggested scope, price, estimated timeline | Limited until accepted |
| Contract | Both parties | Scope, schedule, payment, rights, warranty, termination | Yes |
| Change order | Both parties | Extra work added later and its price | Yes |
What should the scope clause of a web design contract include?
Scope is the most important clause in a web design contract, because every other clause depends on it. A vague scope also fuels arguments about payment and timing. So ask for an annex that lists pages, languages and features one by one.
- Page list: home page, service pages, contact, blog template and so on.
- Number of languages and who handles translation.
- Features: contact form, booking, payments, member area, search.
- Admin panel access and whether you can update content yourself.
- Basic SEO setup, XML sitemap and redirects.
- Work that falls OUTSIDE the scope, under its own heading.
Above all, the last item gets missed. For example, logo design, photography and copywriting rarely appear in a standard proposal. Seeing out of scope work in writing lowers the risk of surprise invoices. Also, the choice between a template and a custom build changes scope directly; we discuss that decision in website template vs custom web design.
How should a web design contract define revision rounds?
The revision clause should state how many rounds of changes you get and what one round covers. For example, a line that only says "reasonable revisions" leaves room for both sides to disagree. Instead, write the number of rounds for each phase and how you will collect feedback.
We suggest one clear distinction: a correction and a change are not the same thing. Specifically, a typo, a color shade or a spacing tweak counts as a correction. Adding a new page or redoing an approved design counts as a scope change. In addition, a single feedback rule speeds things up. In other words, each round arrives as one list from one person.
- Number of revision rounds in each phase: design, development, content.
- How soon you also send feedback within a round.
- How the team charges for going back to a phase you already approved.
- Who gives feedback and who then gives final approval.
Final approval also matters a lot. On the other hand, if your business has several decision makers, naming one authorized contact in the contract prevents most delays.
Which phases should the delivery schedule cover?
Splitting the project into phases protects both parties better than a single deadline. A typical web design contract lists discovery, design, development, content entry, testing and launch as separate stages. Each stage then ends with a written sign off.
- Discovery and brief approval.
- Design mockups and approval.
- Development and review on a staging site.
- Content entry and final checks.
- Launch and handover record.
The point most schedules forget is who causes a delay. Most contracts say what happens if the team runs late. However, they rarely say how the timeline shifts when the client does not deliver content or approvals. So add a sentence such as "if the client causes a delay, the schedule moves by the same amount of time." We do not quote day counts here, because the right duration depends entirely on project size.
If you want a launch checklist, see our website launch checklist.
How should a web design contract tie payments to milestones?
The payment clause should say when each amount falls due and under which condition. In practice, the healthiest structure ties every payment to a concrete deliverable. For example, a first payment at signing, a second at design approval and a final payment at launch.
We do not suggest percentages, because the split depends on the project and on what both sides agree. Still, the contract should answer these questions clearly:
- Does the price include taxes?
- Which currency and which exchange rate apply to invoices?
- What happens if a payment is late, and does work pause?
- How does the team price extra work?
- Who pays third party costs such as theme licenses, plugins and hosting?
We explain the factors behind pricing in business website cost and pricing factors. You can also use our VAT calculator for rough math. That said, confirm current rates and invoicing rules with your accountant. Also, this article is not tax advice.
Who should own the intellectual property and source code?
The intellectual property clause says who gets the rights to the design, the software and the content. For instance, many owners assume they own every part of a site they paid for. In reality, ownership depends on what the contract says. Therefore, make sure it spells out the handover of design files, custom code and source files.
So it helps to separate three layers. First, the design and code the team builds only for you; rights to these normally pass to you on full payment. Second, reusable components the team uses across many projects; for these, the team usually grants a license to use. Third, third party themes, plugins, fonts and images, which follow their own license terms.
- When the rights transfer, often at the final payment.
- Which formats the team uses to deliver source code and design files.
- Whose name appears on third party licenses.
- Whether the team may show the work in its portfolio.
In short, a single line like "all rights belong to the client" is not enough. The contract should state which part transfers and under what condition.
Whose name should the domain and hosting accounts be under?
We recommend that the business opens domain and hosting accounts in its own name, with its own email address. The team can then access these accounts as an authorized user, while ownership stays with you. Writing this into the contract also makes life much easier if you ever switch providers.
ICANN explains why registrant status matters on its information page for registrants. You can check the registration details of your own domain with our WHOIS lookup tool.
- Is the business the registrant of the domain?
- Who holds the main account for hosting, email and DNS?
- Who also owns Google Search Console, Analytics and ad accounts?
- How will the team share passwords securely at handover?
Also check the SSL certificate on launch day. Our SSL checker shows whether it covers the right domain and when it expires.
How should the contract split responsibility for content?
The content clause sets out who provides text, images and product data, by which date and in which format. In practice, this is where most projects stall. The design is ready, but the site cannot go live because the copy never arrived.
The contract should also cover legal responsibility for content. For example, copyright on images you supply and the accuracy of claims in your text usually remain your responsibility. If the team provides stock images or copywriting, list their license and scope on a separate line.
- Who writes the content and who approves it?
- Where do images come from, and whose name is on the license?
- Does the team enter content into the site, or do you?
- How does late content affect the schedule and payments?
For instance, this sentence works well: "The client delivers content by the agreed date after design approval; if content is missing, the team may suggest launching with placeholder text." As a result, the project does not wait forever.
How long should the warranty and bug fix period be?
The warranty clause says how long the team fixes defects for free after delivery. Specifically, two distinctions matter here. A bug differs from a new request, and problems that follow changes by you or a third party may fall outside the warranty.
We do not give a day count, because a fair period varies by project. However, the contract should always state the period as a number rather than "a while." It should also say how you report a bug and how quickly the team responds.
- When the warranty starts: launch date or handover record?
- What it covers: code errors, browser issues, broken forms.
- What it excludes: client changes, plugin updates, server problems.
- Reporting channel and response time.
Linking the warranty to a documented test process also makes it stronger. Next, both sides know exactly what state the site was in at handover.
Why should maintenance be a separate clause?
Maintenance is a different service from warranty, so the contract should treat it separately. Warranty covers defects in delivered work. Maintenance, on the other hand, keeps the system current and secure over time. Mixing the two leads to the classic argument of "the warranty ended, so now everything costs extra."
Maintenance usually runs as a monthly or yearly plan under its own agreement or annex. The clause should list which tasks it includes, such as software updates, backups, security monitoring, small content edits and reporting. We describe a typical scope in what is website maintenance.
You may also decide not to buy maintenance. In that case, the contract should state that updates are your responsibility and that later work by the team costs extra. Then nobody holds false expectations.
Why do you need a data processing clause?
If your site collects personal data through forms, accounts or payments, the design team may access that data during development and maintenance. In that case you need a data processing clause or a separate agreement that defines each party's role. In the EU, Article 28 of the General Data Protection Regulation sets out what such an agreement must cover.
- Which data the team can access, and for what purpose.
- Where the data lives and who else receives it.
- Security measures and duties to report a breach.
- Return or deletion of data when the contract ends.
The contract should also say who writes the privacy notice, cookie notice and consent text. The team places them on the site technically, but the legal wording usually remains your job or your lawyer's. For the technical side, see how to build a GDPR compliant website. Also, this section is not legal advice.
What do confidentiality and non compete clauses do?
A confidentiality clause protects the business information, customer lists and strategy you share during the project. Above all, it matters when you build a site for a product or service you have not announced yet.
Non compete clauses need careful wording, however. Asking the team never to work for anyone else in your industry is rarely realistic. Instead, a balanced option is to forbid use of your confidential information and to keep the project out of the portfolio until your launch date.
Confidentiality should also work both ways. You share panel passwords, customer data and internal files; the team shares its methods and pricing. For example, you can agree to use a shared password manager, never send plain text passwords by email, and close all access when the project ends. Finally, the clause should state how long it stays in force after the contract ends.
How should testing, acceptance and handover work?
The acceptance clause defines when the work counts as delivered. That definition affects both the final payment and the start of the warranty. So we recommend a written acceptance process: the team opens a staging site, you review it within a set time, and then both sides sign a handover record.
- The team shares the staging link and a test checklist.
- You browse the site on different devices and browsers.
- You send all issues in one list.
- The team fixes them and asks for approval again.
- Both sides sign the record, and the team hands over accounts and files.
Some contracts say "if no feedback arrives within the set time, the work counts as accepted." This protects the team. Still, you can negotiate a realistic review window.
Which situations should the termination clause cover?
The termination clause explains what happens if the project stops halfway. Nobody likes to think about breaking up while signing. Even so, this is the clause people need most. It should state when either side may end the contract and who delivers what at that point.
- What triggers a right to terminate: late payment, long silence, serious breach.
- How and with how much notice a party gives termination notice.
- How the team charges for work done so far.
- Handover of finished files, code and account access.
The last item matters most. For example, if the project ends during design, you should receive the design files that match what you paid. As a result, you do not have to start from zero with a new team.
How should you read the liability and dispute clauses?
The liability cap sets the maximum responsibility the team accepts if something goes wrong. Many contracts tie this cap to the project fee. That alone is normal. However, you should read separately how the contract handles serious events such as data loss or a security breach.
The dispute clause says which route the parties follow in a disagreement, such as a named court or mediation. Because this clause has real legal weight, leave its interpretation to your lawyer.
Our field observation is simple. Most disputes do not come from courtrooms; they come from vague scope and weak communication. Therefore, clear earlier clauses are the best way to never need this one.
We also suggest that you name the communication channel. Write down which email address receives formal notices, whether a weekly status call happens, and whom to contact in an emergency. Moreover, these records become the clearest evidence of how the project progressed if a dispute ever arises.
How should you manage change requests and extra work?
New ideas come up as a project moves forward, and that is normal. The problem starts when those ideas slip into scope silently. So add a change request process to the contract: you submit the request in writing, the team estimates the impact on time and cost, and work starts after you approve.
- Write the request in one sentence and add the reason.
- The team sends the impact on schedule and cost in writing.
- If you approve, both sides sign a short change order.
- The team adds the work to the plan and updates later phases.
For example, imagine you decide after design approval that you want a multilingual site. That request raises page count, testing load and content needs at once. Without a written process, the team either works for free or sends a surprise invoice later. Either way, the relationship suffers.
In short, the goal is not to block extra work but to make it visible. Then you control your budget, and the team gets fair pay for its effort.
What should a third party license and subscription clause cover?
A modern website rarely consists of one piece. Themes, plugins, fonts, map services, form tools and email infrastructure all depend on third party license or subscription terms. Their yearly renewal costs continue after the project ends, so the contract should list them separately.
- Which themes, plugins and services the site uses.
- Whose account holds each license and who renews it.
- Who tracks renewal dates.
- What you do if a service shuts down or changes its price.
Here is a situation we see often. The team buys a license on its own account, the project ends, and a year later nobody renews it, so updates stop. Therefore, buy licenses on the business account where possible, or list their transfer in the handover record. Also, seeing subscription costs apart from the project fee helps you calculate total cost of ownership.
Should performance and accessibility goals go into the contract?
Yes, at least as general goals. A fast mobile experience, basic accessibility and pages that search engines can crawl all belong to your quality expectations. If you do not write them down, you will not know what to measure at handover.
Asking for a fixed score, however, needs care. Speed results depend on images, plugins and the server, and the team does not control all of these. Instead, wording like the following is fairer:
- The team follows the core performance principles in the web.dev guides.
- The team shares mobile and desktop test results at handover.
- Forms and menus work with a keyboard.
- The team shows basic SEO settings with a checklist at handover.
This way, goals stay measurable, and no one signs up for a number outside their control. Reviewing this list together on launch day also makes acceptance clearer.
What should a web design contract add for a redesign project?
If you are redesigning an existing site, the contract needs more than a new page list. Redirecting old URLs, moving existing content and protecting search visibility are separate work items. Without them, the new site may look great while traffic drops.
- Who builds the redirect map, and who puts it live?
- Which content moves over, which merges and which goes away?
- For how long does the team monitor the site after launch?
We explain the technical side step by step in website redesign without losing SEO rankings. If the server changes too, our guide on changing web hosting without downtime will help.
Which checklist should you use before you sign?
Use the list below to scan the draft in front of you quickly. If you can answer "yes, the contract states this clearly" for each item, your agreement rests on a solid base. If the answer is "no" or "not sure," ask the team to clarify that clause.
- Scope and out of scope work appear in separate lists.
- Revision rounds and the final approver are clear.
- The schedule has phases and covers client side delays.
- Each payment links to a concrete deliverable.
- Intellectual property and source code transfer are clear.
- Domain, hosting and analytics accounts sit in the business name.
- Content responsibility and due dates are clear.
- The warranty period has a number, and maintenance stands apart.
- Data processing and confidentiality clauses exist.
- The termination clause lists the files you receive.
You can share this list with the lawyer who reviews the text. That way, you check the technical side and your advisor checks the legal side.
What are the most common web design contract mistakes?
The mistake we see most is using a generic template from the internet without adapting it. A template helps as a starting point, but it does not contain your specific scope, accounts and deliverables. The second mistake is agreeing to extra work verbally and never writing it down.
- Describing scope in one sentence, such as "a corporate website."
- Letting the team register the domain on its own account.
- Merging warranty and maintenance into one clause.
- Leaving out file handover in case of termination.
- Relying on email threads instead of a signed change order.
Finally, signing the contract and filing it away is also a mistake. Keep the text close during the project and check the relevant clause at each approval. This habit keeps you and the team on the same page. Above all, it helps on long projects, where details from the first weeks are hard to recall months later.
How does the right team make the contract process easier?
A good team raises these clauses before you do. It asks in the first meeting whose name the accounts will use, how many revisions you get and which files you receive at the end. That attitude signals that issues will get solved early.
At Talha Aslan and team, we define scope in a written annex, open accounts in the client's name and hand over source files at delivery. If you want to start your project with the same clarity, you can request a quote through our web design services page. We still recommend that you leave the final legal review to your lawyer.
