Most website disputes are not caused by bad faith. They are caused by two people having different assumptions about the same sentence, discovered three months in when one of them asks for something the other did not price. A contract’s real job is not legal protection. It is making both parties discover their disagreements before the work starts rather than during it.
Here is what should be written down, and what each clause is actually preventing.
Most of the value of a website contract is created before anyone signs it, in the conversation required to write it down clearly.
Primo Collab
Worth stating plainly: this is practical guidance from building websites, not legal advice. For anything with significant money or risk attached, have a lawyer review it.
Scope, in specifics
“A five page website” is not a scope. It is a number that both parties will interpret differently.
A usable scope states:
- How many pages, and which ones. Named, not counted.
- How many unique page templates. Ten pages using two templates is a very different job from ten bespoke layouts, and this is where the largest misunderstandings happen.
- What functionality is included. Contact form, booking, ecommerce, member area, search, integrations, each named explicitly.
- What is explicitly not included. The most valuable section and the one most often omitted.
Who provides the content
This single clause causes more delays than any other issue in web projects.
State plainly who writes the copy, who supplies images, who sources them, and what the deadline is. Then state what happens if content arrives late, because it usually does. Does the timeline shift? Does the project pause? Is there a point at which the developer proceeds with placeholder content and the client accepts it?
A project that stalls for two months waiting on client copy is not a schedule problem. It is a clause nobody wrote.
Revisions, with a countable limit
“Reasonable revisions” means whatever each party wants it to mean. A workable clause specifies:
- How many rounds are included, at which stages.
- What counts as a revision versus a scope change. Changing a headline is a revision. Adding a new section is not.
- What additional rounds cost.
The point is not to restrict the client. It is that unlimited implied revisions eventually make the developer defensive about every change, which is worse for everyone than a clear number and a rate.
Timeline with dependencies stated
A completion date that assumes the client responds within two days, and does not say so, is a date that will be missed and blamed on the developer.
State the target timeline, the client’s response windows it depends on, and how delays on either side affect the schedule.
Payment terms
- Deposit amount and when it is due.
- Milestones and what triggers each payment.
- Final payment terms, and specifically whether it is due at launch or after a review period.
- What happens if payment is late.
The launch question matters. “Due on launch” and “due 30 days after launch” describe very different cash flow situations.
Ownership and access
The clause most often skipped, and the one that matters most after the project ends.
- Who owns the design files, the code, and the content on completion.
- What transfers on final payment.
- Confirmation that the client receives full administrative access to hosting, domain, CMS, and any third party accounts.
- What licensed third party assets are included, and what the client is responsible for renewing.
If a project ends and the client does not fully control what the site runs on, they do not really own the asset they paid for.
What happens after launch
The gap between “the site is live” and “the relationship is defined” is where a lot of friction lives.
- Is there a warranty period for fixing bugs, and how long?
- What counts as a bug versus a new request?
- Is ongoing maintenance included, offered separately, or not offered?
- What are response expectations for urgent issues?
Ending the agreement early
Nobody wants to discuss this at the start, which is exactly why it should be written when everyone is optimistic rather than negotiated when they are not.
- How either party can end the agreement.
- What is owed for work completed.
- What the client receives if the project ends partway through.
The clause checklist
| Clause | Prevents |
|---|---|
| Detailed scope with exclusions | Scope creep and mismatched expectations |
| Content responsibility and deadlines | Indefinite project stalls |
| Countable revision rounds | Endless unbilled iteration |
| Timeline with dependencies | Delay blame disputes |
| Payment milestones | Cash flow and non-payment issues |
| Ownership and access transfer | Client not controlling their own site |
| Post-launch terms | Ambiguity about what support is included |
| Termination terms | Messy, expensive endings |
The mistake to avoid
Skipping the contract because the project is small or the relationship is friendly. Small projects and friendly relationships are exactly where assumptions go unstated, and a friendly relationship is the thing most damaged when the disagreement finally surfaces. A clear two page agreement protects the working relationship better than a handshake does, because it means neither person has to guess what the other assumed.