Own your agency and choose tools

What to put in a website agreement, in plain words

A plain-words website agreement for a one-person AI agency: scope, payments, approvals, who owns the site and accounts, and how either side can leave.

By Volant team

A dog groomer and her web designer agree on a price over coffee. The designer builds the site, the groomer loves it, and she pays. A year later they fall out over a care plan, and the groomer asks for "her website" so her nephew can take over. The designer says the site runs on his hosting account, the theme is his licence, and the domain is registered in his name "to make things easier". Neither of them is being unreasonable. They just never wrote any of it down.

A website agreement is how you write it down. It doesn't need legal language to be useful. It needs to say, in words both of you understand, what you'll build, what it costs, how approvals work, who owns what, and how either side can leave.

This article is general practice for a one-person AI agency, not legal advice. Laws differ by country, so have a lawyer check your standard agreement once.

What should a web design agreement say?

Here's the outline. Each part gets a few plain sentences, and the sections below give sample wording you can adapt.

  1. Who the agreement is between
  2. What you'll build, and what's not included
  3. What you need from the client, and when
  4. Price, deposit and payment dates
  5. Changes and approvals
  6. Who owns the website
  7. Who owns the domain and accounts
  8. Costs from other companies
  9. After launch
  10. Ending the agreement early

A good test for each section: could the client read it aloud to their business partner and have them nod?

Who, what and what's not included

Who. Your business name and the client's, with a contact for each. If the client's business has more than one owner, name who can approve work.

What you'll build. Link to or attach the scope: the pages, the features, the number of design options, and the launch date you're aiming for. Keep this part specific. "A five-page website" is less useful than "Home, About, Services, Gallery and Contact pages, with a contact form that sends to the shop email".

What's not included. A short list stops arguments later. Common examples: copywriting, photography, an online shop, booking systems, logo design, paid advertising, and changes after launch unless there's a care plan.

Sample wording:

We'll build the pages and features listed in the attached scope. Anything not listed there, such as an online shop or booking system, isn't included and will be quoted separately if you'd like it.

What you need from the client, and when

Most delays in website projects are waits: text, photos, logins, feedback. Say what you need and by when, and what happens if it doesn't arrive.

To launch by 30 June, we need your text and photos by 5 June and your feedback on each version within five working days. If these arrive later, the launch date moves by the same amount.

Price, deposit and payments

State the total price, the deposit, when the rest is due, and how the client pays. A deposit before you start is normal, and it's the clearest sign a client is committed.

The price is as quoted. A deposit of half is due before we start; the rest is due before launch. Work starts once the deposit has arrived.

"Arrived" is doing real work in that sentence. A message saying the money has been sent isn't the same as money in your account.

Changes and approvals

Say how many rounds of changes are included, what counts as a change, and how the client approves. Approvals should name an exact version of the site, not "the website", so both of you know what was signed off.

Your price includes two rounds of changes to the design. You approve each version by replying with its version number. Changes after approval, or beyond two rounds, are quoted first.

Who owns the website?

This is the section most agreements get wrong or leave out, and it's the one the dog groomer needed.

Copyright in creative work often starts with the person who made it. In the United States, for example, the Copyright Office explains that a commissioned work is only "made for hire" (owned from the start by the person who ordered it) 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 a question for a lawyer. Other countries have their own rules. The practical lesson is the same everywhere: don't rely on the default. Write down who owns what.

A common, fair arrangement:

  • The client owns the finished website, its text and images they supplied, and the design made for them, once the project is paid in full.
  • You keep your own tools, templates and reusable code, and give the client a permanent right to use them as part of their site.
  • You may show the work in your portfolio, unless the client asks you not to.

Once the project is paid in full, you own the finished website and its content. We keep the general tools and code we use on every project, and you may use them as part of your site for as long as it runs. We may show the site in our portfolio unless you ask us not to.

If you build on a platform that doesn't let a site be moved, say so here. Some platforms have no supported way to export a site for use elsewhere, as the guide to exporting a GoHighLevel website explains. A client should know that before they sign, not when they try to leave.

Who owns the domain and accounts?

Separate the website from the accounts it depends on. The client should own anything their business can't run without: the domain, business email, Google Business Profile, analytics and payment accounts. You get access to do the work.

Most services have roles made for this. Google's help pages, for example, say a Business Profile can have several owners and managers, and managers can do most of what owners can except add or remove people or delete the profile. That's why the guide to adding a manager to a Google Business Profile recommends the manager role for designers. For every other account, who should own client accounts has a table you can copy into the agreement.

Your domain, email, Google Business Profile, analytics and payment accounts are registered in your business's name. We'll use our own login with the access we need, and remove it when our work ends.

The short definition of owner-held accounts is a useful line to paste in here.

Costs from other companies, and after launch

Other companies' costs. Hosting, the domain, paid plugins, fonts or booking tools. Say who pays for each and whether you pass any on.

After launch. Say how long you'll fix problems for free after launch (a fortnight or a month is common), and that ongoing care is a separate plan.

We'll fix any problems with the work we delivered for 30 days after launch. After that, updates and changes are covered by a care plan if you choose one, or quoted as needed.

Ending the agreement early

Things change. A client closes the shop, or the project stalls for months. Say what happens:

  • either side can end the agreement with written notice;
  • the client pays for work done up to that point;
  • you hand over whatever has been paid for, in a form they can use;
  • deposits for work not started are handled as you've agreed (say whether they're refundable).

Either of us can end this agreement by email. You'll pay for the work done up to that date, and we'll hand over everything you've paid for.

How should you sign it?

Keep the agreement to two or three pages, send it with the scope and price, and ask the client to sign or reply "I agree". Keep the signed copy with the client's other details. When you start the next project, reuse the same agreement and change only the scope and price.

Web designers who sell to local businesses end up writing some version of this for every client. The page for web designers running a one-person AI agency shows how the agreement, the scope and the client's accounts fit together across a project, and keeping client accounts in the owner's name covers the accounts part in more detail.

Questions

Questions people ask

What should a web design agreement say?
Who the two parties are, what you'll build and what you won't, what you need from the client and by when, the price and payment dates, how changes and approvals work, who owns the website and each account, what happens after launch, and how either side can end it. This is general practice, not legal advice.
Who owns the website a designer builds?
Whatever the agreement says, which is why it should say it. A common approach is that the client owns the finished site once it's paid for, while the designer keeps the tools and reusable code they bring to every job and may show the work in a portfolio. Copyright rules differ by country, so ask a lawyer where you work.
Should the agreement say who owns the domain?
Yes. The domain, business email, Google Business Profile and payment accounts should be in the client's name, with you given access. Write that down so there's no doubt if you part ways.
Do I need a lawyer for a website agreement?
Using a lawyer once to check your standard agreement is worth it, especially on ownership, liability and ending early. After that, most projects use the same agreement with a new scope and price.
Is an email enough instead of a signed contract?
Something both of you have clearly agreed to in writing is far better than nothing, and for small jobs an email with the terms attached, replied to with 'I agree', is common. Whether it's enough depends on where you are, so check local rules.

Start here

Try one ideaon your next client.

Every how-to here works with a simple notes file. Keep the ones that help, and let Volant keep track when you're ready.

For Mac and Windows. Works with Claude Code.

Join the waitlist