We are regularly asked to take over a website project that has gone wrong, and the pattern is remarkably consistent. The disputes are almost never about design taste. They are about scope, about who owed the content, about what "finished" meant and about who owns the result. Every one of those can be settled in writing before anyone starts.
This is written for the person commissioning the website rather than for a lawyer. If you are comparing proposals right now, it doubles as a checklist. It is general guidance, not legal advice — for a contract of any size, have someone qualified in your jurisdiction read it.
1. Scope: what is actually being built
A contract should name the deliverable in countable terms. "A modern, responsive website" is not a scope, it is a mood. Countable looks like this:
- The number of page templates being designed, and how many pages use each. Twelve pages built from three templates is a very different job from twelve bespoke pages.
- The specific functions: contact form, online booking, payments, a blog, a customer login, multiple languages, a searchable directory.
- Any integrations with software you already use — a CRM, an email platform, an accounting system, a booking tool.
- Which browsers and devices are supported and tested.
- What is explicitly excluded. This single line prevents more arguments than anything else in the document.
If a proposal describes the site only in adjectives, ask for the countable version before you sign. A firm that has delivered many projects will have it to hand; one that resists is telling you something useful.
2. Who owns what at the end
This is the clause that costs people the most and gets the least attention. Settle in writing who owns each of these once the final invoice is paid:
- The website code and the design source files.
- The domain name — it should be registered in your business's name, always, with you as the registrant contact.
- The hosting account.
- The content, photographs and any custom illustration or icon set.
- Your Google Analytics property, Search Console, Business Profile and any ad accounts.
A reasonable agency transfers all of it, or gives you owner-level access. Watch for two specific patterns: a licence to use the site rather than ownership of it, and a domain registered in the agency's name "for convenience". The second is how businesses lose control of their own address. We covered the ways this goes wrong in who owns your website after launch.
If the site is built on a proprietary platform the agency owns, that can be perfectly fine — but you should know it before signing, because it determines whether you can ever move the site elsewhere.
3. Payment schedule, tied to stages
An advance to begin is normal and reasonable; nobody should expect a studio to carry the whole project on credit. What matters is that every later payment is tied to something visible rather than to a date:
- Design approved.
- Build complete on a staging site you can see.
- Site live and signed off.
Dates alone are a weak trigger, because a project can reach week six without reaching stage two. Also check two details that surprise people on launch day: whether the final payment falls due before or after the site goes live, and whether the files are released to your hosting on payment. Both arrangements are normal. Discovering which one applies at the last minute is not.
4. Timeline, and what happens when the client is the delay
Most website projects that overrun do so because the client's content, logins or feedback arrived late — and the client is genuinely busy running a business. A fair contract says so plainly. It gives a timeline that assumes feedback within a stated number of working days, and it says what happens when that does not arrive.
Look for a clause covering a project that goes quiet for an extended period. An abandoned project that restarts six months later costs the studio real money, because the team has moved on and the work has to be picked up cold. A clause about it is a sign of experience, not of hostility.
5. Content: who writes it
This is the single largest cause of overruns in our experience. The client usually assumes copywriting is included; the studio usually assumed it was being supplied. Both are being reasonable, and the project stalls for a month. Settle it explicitly:
- Who writes the page copy, and by when.
- Who supplies photography, and who pays for stock licences if it is needed.
- Who is responsible for migrating content from an existing site, and how much.
- What happens to the launch date if placeholder text is still in place.
If you are supplying the copy, be honest with yourself about whether you will. Paying for copywriting is almost always cheaper than a project sitting idle for six weeks. Our guide to writing a website design brief covers what to prepare before the work starts.
6. Revisions: define a round
"Two rounds of revisions" means nothing until a round is defined. A round should be one consolidated set of feedback, collected from everyone who gets a say, delivered once. Without that definition, feedback arrives in eleven emails over three weeks, the studio feels it has done five rounds, the client feels they have had one, and both are right.
The contract should also distinguish a revision from a new request. Changing a colour, swapping an image or editing a heading is a revision. Adding a booking system is new work. Say how new work is quoted and approved — in writing, before it is built, is the only answer that prevents a surprise at the end.
7. What "launch" means
Define done, in a list. A reasonable definition of launch:
- The site is live on your hosting, under your domain.
- Forms have been tested and arrive in the right inbox.
- Analytics and Search Console are installed under your own accounts.
- Every old URL redirects to its new equivalent.
- The site is indexable — the staging site's block on search engines has been removed.
- You have been shown how to edit the content, with a recording or a document.
The redirect line matters more than it looks. A rebuild that drops the old URLs can lose years of accumulated rankings in a single weekend, and it is a slow, expensive thing to recover. The mechanics are in redesigning a website without losing SEO. The indexable line matters too: leaving the staging block in place on a live site is one of the most common and most costly launch mistakes in the industry.
8. What happens after launch
A website is not furniture. The platform updates, plugins break, certificates expire and things need patching. The contract should say which of this is included and for how long:
- A defect period — how long after launch genuine bugs are fixed at no charge.
- Whether software updates, backups, monitoring and security are included or sold separately.
- Response times for something that is actually broken, and how to report it.
- The hourly or monthly rate for anything outside that.
Be clear about the difference between a bug and a change. A form that does not send is a bug. A form that needs two more fields is a change. Studios and clients rarely disagree about this once it is written down, and almost always disagree about it when it is not.
9. Third-party costs
Domains, hosting, premium plugins, stock photography, commercial font licences, an email platform and payment processing all cost money every year, and they are frequently absent from a quoted build price. Ask for the expected annual running cost in writing, and ask whose name each account is in.
This is also where a surprising number of businesses end up paying twice: once to the studio as a marked-up rebill, and again when they discover they could hold the account directly. Neither arrangement is wrong. Not knowing which one you have is.
10. Confidentiality and credit
If the studio intends to put the project in its portfolio, that is normal and usually good for you too. But if your project is confidential until launch — a new brand, a funding round, a competitor-sensitive product — say so in the contract rather than hoping.
Equally, check whether a credit link in your footer is required, for how long, and whether you may remove it. A small line, but worth knowing before it is live on every page of your site.
11. How either side can end it
Projects end for reasons nobody predicted: funding changes, a founder leaves, priorities move. A fair contract says how either party may stop, what is owed for work already completed, and what you receive if it ends mid-project.
Without this clause a stalled project becomes a standoff in which you have paid for something you cannot use and cannot take elsewhere. With it, an unfortunate situation stays merely unfortunate.
Questions worth asking before you sign
- Who owns the code and the design files once I have paid in full?
- Whose name is on the domain registration?
- What is explicitly excluded from this quote?
- Who writes the copy, and what happens to the date if it is late?
- What is the total annual running cost after launch?
- What does a revision round mean here?
- What is included in the defect period, and for how long?
- What happens if either of us needs to stop?
- Can I see the contract before the deposit rather than after?
None of this is about distrust. A clear contract protects a good studio as much as it protects the client — it is what lets them say no to scope creep without an argument — and the firms worth hiring will be pleased you asked. Our guide to choosing a web design company covers what else to look at before you get this far.
If you would like to see how we set this out before a project starts, look at our web design work or contact us.
