A website design contract is the most important document you sign before a project starts, and most disputes between a client and a designer begin with clauses that were either never written or written vaguely. In this article we go through a practical list of the clauses every website design contract should have, with sample wording and red flags. This is a practical guide to help you prepare, not legal advice; always have a lawyer or legal adviser review the final version of the contract.
Why do you need a written, detailed website design contract?
Website design is a project that runs for several weeks, and both sides make decisions all the way through: which pages get built, how the site should look, who supplies the content and when the work counts as "finished". When those decisions are scattered across messages and phone calls, sooner or later the two sides remember them differently. These are the most common sources of disputes:
- Scope creep: the client sees a feature as "obvious", the designer sees it as outside the agreement.
- Delays: each side blames the other for the project falling behind.
- Payment: it is unclear exactly which delivery triggers the next installment.
- Ownership: the domain or hosting is registered in the designer's name, and once the work ends, the client has no access to their own website.
A good contract is not a sign of distrust. On the contrary, it makes the collaboration smoother by making expectations clear. A professional designer usually welcomes a detailed contract, because it protects them too. Before you get to the contract, it also helps to know which costs usually don't appear in a quote; our article on the hidden costs of website design lists them.
Quick checklist of contract clauses
Before getting into the details, keep this table next to your draft contract and tick it off clause by clause:
| Clause | What it defines | Red flag |
|---|---|---|
| Scope of work | Pages, features and what is out of scope | Vague phrases like "a complete website" |
| Deliverables | Files, access, documentation and training | Only "website handover" with no detail |
| Timeline | Phases and the date of each phase | Only an end date for the whole project |
| Payment | The amount of each installment and what triggers it | Full payment before work starts |
| Revisions | Number of revision rounds in each phase | "Unlimited revisions", or no such clause at all |
| Content | Who supplies text and images, and by when | Silence about content |
| Ownership | Domain, hosting, source code, licenses | Domain or hosting registered in the designer's name |
| Support and warranty | Length of free bug fixing and later services | No definition of a "bug" |
| Confidentiality | Protection of both sides' information | No clause, or a one-sided clause |
| Termination | Exit conditions and settlement for work done | No termination clause |
Below we look at each clause in more detail.
Scope of work and deliverables: the foundation of any website design contract
Write the scope of work as a list
Instead of "corporate website design", list the pages and features. For example: home page, about us, three service pages, blog, contact us, a consultation request form that sends to email, a responsive mobile version and basic SEO (meta titles and descriptions, sitemap). If the site is multilingual, an online store or has a user dashboard, state exactly what is included. The build platform belongs in this clause too: whether the site is built on WordPress or custom-coded directly affects cost, maintenance and ownership. If you are still deciding between the two, our article on WordPress vs custom-coded website design will help.
State what is out of scope, explicitly
A clause titled "Outside the scope of this contract" settles many disputes before they happen. Items such as writing text content, photography, buying the domain and hosting, advertising, ongoing SEO after handover or integration with accounting software should be named here if they are not included in the price.
Make the deliverables concrete
What exactly will you receive at the end of the project? A good list usually includes:
- The website launched on the client's domain and hosting
- The username and password for the site's main admin account, the hosting and the database
- The source code and design files (for example, the Figma file), in line with what was agreed about ownership
- A list of the theme, plugins and paid services used, and the status of their licenses
- One full backup at handover
- A training session or video on using the admin panel
Timeline, milestones and staged payments in a website design contract
Break the project into deliverable phases
An end date on its own is not enough. Divide the project into several milestones, each with a visible output, for example:
- Requirements and page map (sitemap)
- Home page UI design and its approval
- Design of the remaining pages
- Development and launch on a staging version
- Testing, final fixes and move to the main domain
For each phase, write the designer's working time and the client's review and response time separately. Many delays come from the client side, such as content or approvals arriving late. Add a clause saying that if the client's response is late, the timeline shifts by the same amount, and what happens if the designer falls behind without a valid reason.
Tie each installment to a delivery
The most sensible payment structure is an upfront payment to start the work, with the rest in installments that each fall due after a milestone is approved. Sample wording: "The second installment is payable after the client approves the home page design in writing." Pay attention to these points as well:
- Definition of "approval": how approval is given (email, a specific messaging app) and what happens if the client doesn't respond within a set period.
- Final installment: this is best paid after launch on the main domain and handover of all access, not before.
- Taxes and additional charges: make clear whether the contract amount includes any applicable taxes and statutory charges. Check this with your own accountant too, because the rules can change.
- Third-party costs: are the domain, hosting, theme and plugin licenses included in the price, or does the client pay for them separately?
For an initial budget estimate and an overview of our packages, see our website design pricing.
Keep revisions and change requests separate
"Unlimited revisions" sounds attractive, but it usually either never happens in practice or makes the project endless. The contract should separate two ideas:
- Revision: a change within what has already been agreed, such as changing the color of a section or rearranging a layout. Set the number of revision rounds for each phase (for example, two rounds for the home page design).
- Change request: adding something that was not in the scope of work, such as a new page, a second language or a new feature. Write down how these requests are logged, priced and added to the timeline.
A practical tip: send all feedback for each round together, in one list, not in pieces. It makes the designer's job easier and keeps the round count transparent.
Who is responsible for the website content?
Content that isn't ready is one of the most common reasons projects stall. The contract should make clear:
- Who writes the page copy and, if it is the designer, how it is edited and approved.
- Where the images come from: the client's own photos, custom photography or licensed stock libraries.
- The client is responsible for the copyright of images and text they supply, and the designer commits not to use unlicensed images and fonts.
- The deadline for delivering content, and whether the designer moves ahead with placeholder text or the work stops if the content doesn't arrive.
If the site is meant to be search-optimized from the start, state whether the content of each page will be prepared with keywords in mind or whether that is a separate service.
Ownership of source code, domain, hosting and accounts
This may be the most important clause for the future of your business, because its effect remains even after the collaboration ends.
Domain
The domain should be registered in the client's own name and details. In practice, that means registering it through an account the client holds with the domain registrar; check the current procedure and requirements with your registrar. If the designer registers the domain for you, state in the contract that it will be registered in the client's name and that the account details will be handed over. To understand the difference between a domain and hosting and how each is registered, see our domain and hosting guide. Create the domain account with an email address and mobile number that belong to the business itself, not to an employee or contractor.
Hosting and server
The hosting or server account should also be in the client's name, with full admin access given to them. If the site is hosted on the designer's server, write down the terms for moving to another host and for handing over a full backup if the collaboration ends.
Source code, design files and licenses
Make clear that after full payment, ownership of, or unlimited rights to use, the source code and design files transfer to the client. Keep two common exceptions in mind: libraries and modules the designer uses across different projects (usually only the right to use them is transferred), and commercial themes and plugins whose licenses follow the original developer's terms. Also state whether the designer may show the project in their own portfolio or résumé.
Support, warranty period and confidentiality
Bug-fix warranty period
After handover, a set period is usually agreed during which technical bugs caused by the designer's work are fixed for free. The key to this clause is the definition of a "bug": behavior that does not match the agreed scope of work. New features, design changes based on taste, or problems caused by other people's edits or by plugins the client installs are usually not covered by the warranty. Write down the length of the period, how bugs are reported and the response time.
Support after the warranty
After the warranty period, what happens with updates, backups and fixes? If there is a separate support contract, refer to it, or at least set out how the cost of later services is calculated. This matters even more for WordPress sites, because without regular updates the site's security gradually weakens.
Confidentiality
During the project, the designer gets access to information such as your customer list, prices, logins and business plans. The confidentiality clause should define what information is confidential, state that the designer may not disclose it or use it for other work, and that this obligation continues after the contract ends. It is best for this clause to be mutual, because the designer's information and working methods also need protection.
Terminating the contract and settling mid-project
Nobody signs a contract expecting to part ways, but the termination clause exists precisely for the day the collaboration cannot continue, for whatever reason. Make these points clear:
- Grounds for termination: when each side has the right to terminate; for example, a long delay without a valid reason, non-payment of an installment that is due, or content not being delivered for a long time.
- Notice: termination is given in writing, with how much prior notice.
- Settlement for work done: based on the milestones delivered, which parts the client pays for and which amounts the designer must refund.
- Handover on termination: files, source code and access for the parts that have been paid for are handed over to the client.
- Dispute resolution: before going to court or the authorities, how negotiation or arbitration through an agreed person or body takes place. Set out the exact mechanism of this clause with your lawyer.
Do these things before you sign
- Check the full details of both parties, the amount in figures and in words, and the dates.
- Every important verbal promise made in meetings should appear in the contract or its appendix.
- Attach the scope of work, timeline and list of deliverables as a signed appendix. If you have written a website design brief, use it as the basis for the scope of work.
- Give the final text to a lawyer or legal adviser before signing, especially the clauses on ownership, termination and dispute resolution.
Warning signs before you sign a website design contract
The table above is for checking the contract text, but some signs show up much earlier, in the quote or in the very first meeting. If you see any of these, hold off on any payment and ask for a written explanation:
- "We don't need a contract, we trust each other." Without a written contract, you have nothing to refer to if a dispute arises.
- A request for full payment before work starts. This removes your leverage for getting a complete handover.
- An offer to register the domain or hosting in the designer's name "for convenience".
- A quote with just one number and the phrase "complete website", without a list of pages and features.
- A promise of "unlimited revisions" without making clear what a revision is and what counts as a change request.
- A price that can only be explained by a nulled theme or plugin. If theme and plugin licenses are not in the proposal, ask where they come from.
- Silence about termination, or a vague answer to the question "What happens if we part ways mid-project?".
- A guarantee of the first spot on Google or a specific level of sales. Nobody can guarantee search results or buyer behavior.
Ask these questions out loud in the meeting
- In whose name will the domain, hosting and main admin account be registered?
- Where do the paid theme and plugins come from, and who is responsible for renewing their licenses?
- Exactly which phase's delivery triggers each installment?
- How many review rounds do I get, and how are requests outside the scope of work priced?
- If one of us wants to stop the work, how is the settlement done?
- After handover, how long is bug fixing free, and what exactly counts as a "bug"?
An evasive answer to any of these questions is an answer in itself.
For comparison, these are MyTarh's written terms: a written contract before work starts, 50% upfront and 50% after delivery, three free review rounds after the initial presentation, full transfer of ownership of the code and custom design after full payment, a 1–3 month bug-fix warranty depending on the plan, and the option to terminate with 14 days' notice and settlement for the work done. Read the full text on our terms of service page and a summary of the process in how we work with MyTarh, and ask us these same questions too.
Frequently asked questions
Do I need a written contract even for a simple website?
Yes. Even for a small project, a short contract covering the scope of work, the price, the timeline, ownership of the domain and hosting, and the warranty period prevents most misunderstandings. The contract doesn't need to be long; it needs to be precise.
How much is the usual upfront payment for website design?
There is no fixed or legally set figure; it depends on what both sides agree and on the size of the project. More important than the upfront percentage is that the rest of the amount is tied to specific, visible milestones and that the final installment is paid after full handover.
What should I do if the designer registered the domain in their own name?
First, ask in writing for the domain to be transferred to your name. The transfer procedure depends on the type of domain and the registrar, and you need to follow it up with the registrar or registry responsible for that domain. In future contracts, write this clause in from the start.
Can I use ready-made contract templates from the internet?
Templates are useful for getting started and listing the clauses, but they usually don't match the details of your project. Use them as a draft, write the scope of work and timeline specifically for your project, and give the final version to a lawyer.
Is bug fixing free after the warranty period ends?
Usually not, unless you have a separate support contract or something else was agreed in the main contract. That is why it is best to ask about the terms and cost of post-handover services before you sign.
A clear contract makes a project predictable from day one. If you want help defining the scope of work, phases and deliverables for your project, we can go through them together in a free consultation call with MyTarh. See our website design services page or go straight to place an order.