What to check in a web design contract.

The short answer

A good web design contract lets someone who was not in your meetings understand what is being built, what it costs, who owns what at the end and how either side can leave. If yours cannot do that, it will not help you when there is a disagreement.

Before you sign, you should be able to answer these from the contract alone:

• Which pages, features and connections are included, and which are not?
• How many rounds of design changes are included, and what counts as a round?
• What is each payment for, and what will you have seen before it is due?
• Who owns the design, the code and the content once you have paid?
• In whose name are the domain, the hosting and every account?
• What is fixed after launch, for how long and how fast?
• If either side stops early, what do you pay and what do you receive?

Anything promised on a call is hard to rely on later unless the contract, or a plan attached to it, says it. For a large project, or when you are signing the designer's standard terms, ask a lawyer to read the contract first.

What is being built

Vague scope is where disputes start. "A modern five-page website" can mean very different jobs. The contract, or a plan it refers to, should list:

• Each page and what it is for.
• Features such as booking, a members area, a chatbot or an online store, with the number of products and how they get loaded.
• Connections to your other tools, such as a booking system or a CRM, and what happens if a tool does not allow what was planned.
• Who writes the text and supplies the photos, and by when.
• The platform, and who holds the licences for paid themes, plugins and fonts.
• Testing on named phones and browsers, and against an accessibility standard such as WCAG 2.1 AA if the site needs one. See ADA website accessibility.
• For a website redesign, redirects from every old page address that changes.
• What is not included, in writing.

The last line matters as much as the rest. A plan that says what is not included saves an argument later.

GGSites, for example, sends a written plan before work starts that lists each page and its purpose, the platform and why, the connections to your other tools, who writes the words and what is not included. Whoever you hire, ask for something like it and attach it to the contract.

What revisions means

Every contract mentions revisions, and few define them. Pin down:

• How many rounds of design changes are included, and at which stages.
• What counts as a round: one set of comments sent together, not every email.
• What counts as a change and what counts as new work. Moving a button is a change. Adding a page is new work.
• How new work is priced and agreed before it starts.
• How long you have to send comments, and what happens to the timeline if you take longer.

Collect your team's comments into one list per round, from the person who decides. Two people sending different notes about the same page can use up a round and leave the designer guessing.

Unlimited revisions sound generous and are often a warning sign. Without a definition of what a revision is, the scope was probably never pinned down either.

Dates, and your part of the work

A website timeline depends on you as much as on the designer, because the text, photos, logins and comments all come from your side. Check that the contract or the plan names:

• When you send the text, the photos, the logo files and the logins.
• How long you have to review each stage.
• Whether the launch date is a target or a commitment, and what moves it.
• Who on your side decides, so comments come from one person.

If a date really cannot move, such as the opening of a new branch, say so before you sign, so the plan is built backwards from it.

Payment stages

Payments should follow work you can see. Two common structures are a deposit at the start with the rest at launch, and a deposit with payments at milestones such as approved designs and a working preview. Check:

• What each payment is for, and what you will have seen before it is due.
• What triggers the final payment: the launch, your approval or a fixed date.
• What happens if the project stalls while the designer waits for your content. Some contracts let the designer invoice for work done after a set period, so know how long it is.
• Late payment terms.
• Whether third-party costs, such as plugins, stock photos or a store plan, are in the price or billed on top.

GGSites takes the setup fee in two halves: half when work starts, and half when the site is live and you are happy with it. Our prices page shows the figures.

Be wary of paying everything up front for a custom build, and of a final payment due on a date whether or not the site works.

Who owns the design and the code

Paying for a website does not by itself make you the owner of everything in it. The contract has to say so.

In the US, the Copyright Office explains that work commissioned from an independent contractor is a work made for hire, owned by the client, only if it falls into one of nine listed categories and both sides sign a written agreement saying so. Whether a website fits those categories is uncertain, which is why careful contracts add a written assignment of copyright. US law requires a transfer of copyright to be in writing and signed by the owner.

In the UK, the author of a work is its first owner unless they made it as your employee, and an assignment of copyright only works in writing signed by the person assigning it. In Germany, copyright itself cannot be transferred at all, so the contract grants you rights to use the work instead. Other countries differ again, which is a reason to have this clause read where you are. Look for:

• The design, the code written for you and the content you supplied become yours, or are licensed to you without limits, once you have paid.
• The designer keeps their own tools, code libraries and know-how, and gives you a licence to use the parts in your site. That is normal.
• Themes, plugins, fonts and stock photos are licensed rather than owned. The contract should say whose name the licences are in, and they should be in yours where the licence allows.
• You receive the design files and a copy or export of the site on request.
• The designer may show the site in their portfolio, if you agree.

Watch for a clause that keeps ownership with the designer until a long monthly plan ends, with no way to buy it out. Ask in writing what you could take with you at each point of the contract.

What counts as finished

The final payment usually depends on the site being finished, so the contract should say what finished means. Without that, launch day turns into a negotiation. Look for:

• A list of what must work before launch: every page in the plan, each form arriving in the right inbox, the booking or payment step, and the site checked on named phones and browsers.
• A review period after you receive the preview, and what happens to problems you report during it.
• What counts as acceptance: your written approval, the site going live, or the end of the review period with no comments.
• Who moves the site to your domain, and when.
• How problems found after acceptance are handled: under the warranty period, or as new work.

Test the preview yourself before you approve it. Send each form from your phone, open every page and check the details customers rely on, such as prices, opening hours, the address and the phone number.

The domain, hosting and accounts

The domain is the part you can least afford to lose, because your website and your email depend on it. It should be registered in the business's name, with the business as the registrant, in an account you control. The designer can be added as a user. The contract should say:

• Who registers and renews the domain, and in whose name.
• Who holds the hosting account, and in whose name.
• That the logins for the website, hosting, domain, analytics, Search Console and your Google Business Profile are set up in your name from the start, or handed over.
• How access is shared: invitations to user accounts, never passwords by email.

GGSites sets up the domain, hosting and accounts in the client's name, or hands them over at launch. If a past designer holds yours, read how to get your website back and ask while you are still on good terms.

Hosting, support and changes after launch

Hosting and support often sit in a separate agreement or a monthly plan. Read it as carefully as the build contract:

• What the monthly fee includes: hosting, updates, backups and small edits, and how many edits.
• How fast they respond when the site is down, and how you reach them.
• The notice period to stop, and whether there is a minimum term.
• What you receive when you leave: the site files, a database export, the domain and every login.
• What happens to email on your domain if it runs on their hosting.

A warranty period is worth having in writing: defects that were in the build are fixed free for a set time, separately from new requests. Ask for the length of that period and what counts as a defect. Our guide to website maintenance goes through each line a monthly plan should cover.

If the site will connect to other systems through an automation, ask who fixes it when a connection fails and how you will hear about it.

Ending the contract early

Projects stop for ordinary reasons: the business changes its plans, the designer falls ill or the relationship breaks down. The contract should say:

• How either side can end it, and with how much notice.
• What you pay for work done up to that point, and how that work is measured.
• What you receive for it: designs, code and content in a form another designer can use.
• What happens to a deposit paid for work not yet done.

Without this clause, ending a project can mean losing both the money and the work.

Liability, content and compliance

A few clauses look like boilerplate and are worth a minute each:

• You will usually promise that you have the right to use the photos and text you send, so never send photos you found online.
• The designer should promise that their design and code are not copied from anyone else, and that stock images are properly licensed.
• Most contracts cap what the designer owes if something goes wrong. Check the cap is sensible compared with what you are paying.
• The contract should say who is responsible for the cookie banner, the privacy notice and any accessibility standard. If the designer hosts your forms or can read your enquiries, the GDPR requires a data processing agreement between you.
• Check which country's or state's law applies, and how a dispute would be handled.

Red flags before you sign

• No written scope, or a scope of one line.
• The domain registered in the designer's name.
• Ownership that passes only when a long monthly plan ends, with no buy-out.
• Unlimited revisions with no definition.
• A total price with no list of what it covers.
• Nothing about what happens if either side wants to stop.
• Pressure to sign quickly, or a deposit requested before you have seen a contract.

The questions to ask before you get to the contract stage are in questions to ask a web designer, and how to compare quotes is in what decides the price of a website.