Most disputes over a website are not about quality. They are about something both sides assumed differently and nobody wrote down. Four clauses cause nearly all of it.
1. Who owns what at the end
The most important clause and the one most often missing. On the day the project ends, in your name and on accounts you can log into, you should have:
- The domain.
- The hosting account.
- The site files and database.
- Analytics, Search Console and any ad accounts.
- The content — your words and photographs.
It is common for these to sit in the developer's accounts "for convenience". It works fine until you want to change developer, or they stop replying. Then the address your customers know belongs to somebody else. Insist on this one; it is the hardest to fix afterwards.
2. What a revision is, and how many you get
"Unlimited revisions" sounds generous and is the most common source of a stalled project — there is no definition of done, so the project ends when somebody loses patience.
A fair contract says a number, defines what counts, and says what happens after. Two rounds at each review stage is normal. It should also distinguish a revision from a change of scope: adjusting a colour is a revision, adding a booking system is not.
3. What is actually included
The scope should list what you get, in enough detail that you could hand it to a different developer and get the same thing. Specifically:
- Who writes the content, and who supplies photographs. The most common reason projects stall.
- How many distinct page layouts, not how many pages.
- Whether SEO groundwork is in — titles, descriptions, sitemap, redirects from any old site.
- Whether training is in, so somebody can edit pages afterwards.
- What is explicitly out. A contract that names exclusions is a sign of someone who has done this before.
4. What happens after launch
Three things need a number, not a sentiment:
- A warranty window for fixing things that were built wrong, free.
- Response times, with the site being completely down treated differently from a typo.
- Who applies updates, and whether that is included or billed.
Our maintenance piece covers what that second phase should contain.
Payment terms that protect both sides
A deposit before work starts is normal and reasonable. Full payment up front is not. Milestones tied to deliverables rather than dates protect you both — nobody is owed money for a stage that has not happened, and nobody is working unpaid for months.
Make sure it also says what happens if you cancel midway, and what happens if the developer does.
The one worth walking away over
If a developer will not agree that you own the domain and the accounts in your own name, that is not a negotiating position — it is the business model. Everything else on this page can be compromised on. That one cannot.
If there is no written contract at all
For a small project, an email covering these five points — scope, revisions, ownership, payment stages, what happens after launch — confirmed by a reply, is far better than nothing and takes fifteen minutes. Most disputes we hear about would not have happened with that email.
Our own terms are published on the site rather than sent on request, which is a reasonable thing to expect from anyone you are considering. Tell us about your project and the scope comes in writing before anybody starts.