Most website disputes aren’t caused by bad faith. They’re caused by two parties holding reasonable but different assumptions that nobody wrote down. A good contract is mostly an assumption-flushing exercise.
This article is general information, not legal advice. Contract law varies by jurisdiction. Have a qualified lawyer where you are review any agreement before you sign it. It is also worth saying plainly that we are a web studio writing about what to demand from a web studio’s contract — everything below is what we would want a client to bring to us.
The 12 clauses
1. Scope of work
The most important clause in the document, and the most commonly vague.
Must specify: exact number of pages, number of unique page templates (different from page count), functionality to be built, platform and CMS, whether the design is custom or template-based, and which third-party integrations are included. Must also specify what’s excluded: copywriting, photography, logo design, SEO campaigns, ongoing maintenance, training, hosting costs. Explicit exclusions prevent more arguments than explicit inclusions.
2. Deliverables
List what you actually receive, in what format:
- Wireframes and design files, and whether you get editable source files
- The live site on your hosting
- Source code and repository access
- Written documentation and credentials
- A CMS training session or a recording of one
“A completed website” is not a deliverable list.
3. Timeline and milestones
Dates attached to phases, not a single launch date. The contract should carry phase-by-phase dates, client review windows (48–72 hours is reasonable), and — critically — what happens when a deadline slips.
The clause should state that client delays shift subsequent dates, and should also hold the developer to something if they are the cause. One-sided timeline clauses are common. Ask for symmetry; the answer tells you something either way.
4. Payment schedule
Standard structure: a 30–50% deposit to begin, one or two milestone payments, and the final balance on completion but before the site goes live on your domain. What that payment schedule attaches to matters more than the headline figure.
Also define: accepted payment methods, invoice terms (net 14 or net 30), late payment interest, and what “completion” means precisely — otherwise the final payment trigger is a matter of opinion.
Never pay 100% upfront. A developer who insists on it has removed every incentive to finish on time.
5. Revisions
Define how many rounds are included per phase (two is standard), what constitutes a “round” versus a new request, what happens beyond the included rounds, and the hourly rate for extra work.
A round means one consolidated set of feedback, not five separate emails over a week. Write that down, because it is the most common source of quiet resentment on both sides.
6. Content responsibilities
State who provides text, images, video and product data, and by when. Include what happens if content arrives late — typically the timeline shifts and a storage or re-engagement fee may apply after a defined period.
Content is the single most common cause of project delay. A clause that names a content deadline is worth more than most of the legal language in the document.
7. Intellectual property ownership
The clause most likely to be quietly unfavourable.
You want full ownership of the final design and custom code transferring to you on final payment. Ownership transferring on payment rather than on signature is normal and fair.
Expect carve-outs. The developer retains rights to their pre-existing frameworks, libraries and reusable components; third-party themes and plugins remain under their own licences; open-source components keep their original licences. These are reasonable — just make sure they don’t extend to your custom work.
Watch for: clauses granting the developer a perpetual licence to your content, or making ownership contingent on an ongoing retainer.
8. Hosting, domain and account ownership
Separate from IP, and frequently overlooked.
Everything should be registered to your business, in accounts you control: domain registrar, hosting, CMS admin, DNS, analytics, Search Console, code repository, and any third-party services. Grant the developer access to your accounts — don’t let them create accounts in their own name on your behalf.
This clause prevents the worst outcome in web projects: a business unable to access its own website because a former contractor controls the registrar.
9. Confidentiality
Mutual NDA terms covering business information shared during the project. Also address whether the developer may display the project in their portfolio and reference you as a client — most will want to, and most clients agree, but it should be a decision rather than an assumption.
10. Warranty and post-launch support
Standard: 30–90 days of bug fixes at no charge after launch.
Define carefully: what counts as a bug (something not working as specified) versus a new feature request (something not in the original scope). Also state the hourly rate or retainer cost after the warranty window, and expected response times.
11. Change orders
Scope changes are normal. Unmanaged scope changes destroy projects. The clause should state that changes outside the agreed scope require written approval, with a documented cost and timeline impact before work proceeds.
This protects both sides — it stops you being invoiced for things you didn’t authorise, and stops the developer absorbing unpaid work.
12. Termination and kill fee
The clause nobody reads until they need it.
Should cover: how either party terminates and with what notice, what you pay for work completed to date, whether you receive the work-in-progress files, and any kill fee. A kill fee of 25–50% of the remaining balance is common for client-initiated cancellation without cause.
Also useful: a dispute resolution step — mediation before litigation — and the governing jurisdiction, which matters considerably if your developer is in another country.
What to look for in a proposal
Before the contract comes the proposal. A strong one demonstrates understanding, not just pricing.
Good signs:
- It restates your goals and problems in their own words, showing they listened
- Scope is itemised, with exclusions named explicitly
- A phased timeline with dependencies identified
- Relevant examples of similar work, with outcomes
- A clear statement of what they need from you
- Assumptions listed openly
Warning signs:
- A single price with no breakdown
- Generic content that could be sent to any client
- No timeline, or a suspiciously short one
- No mention of what is excluded
- No mention of what they need from you
- Guaranteed rankings or traffic numbers
- Heavy pressure to sign within days
Ask for changes before signing. A developer’s willingness to adjust a proposal or clarify a clause tells you a lot about how the next eight weeks will go — and it is a cheaper test than finding out later.
How to write a website design brief
A clear brief reduces cost, shortens timelines and improves quotes. It also makes quotes comparable, which is the part most people skip.
- Business context — what you do, who you serve, what makes you different
- Project goals — the one primary action visitors should take, and how you will measure success
- Target audience — who they are and what they need in order to decide
- Scope — approximate page count, required functionality, integrations
- Content — what exists, what needs creating, who is writing it
- Design direction — three reference sites with a note on what you like about each, plus brand assets
- Technical requirements — existing platform, hosting, tools that must integrate
- Budget range and deadline — withholding these wastes everyone’s time and produces quotes you cannot compare
- Decision-maker — one named person with approval authority
- Success criteria — what “done well” looks like in concrete terms
Send the same brief to every candidate. It is the only way to compare quotes meaningfully, and it matters more than who you hire.
What to do if your developer goes silent
It happens. Handle it in this order, because the order matters:
- Send one clear written message. Summarise outstanding deliverables, reference the relevant contract clause, and set a specific response deadline — three to five business days is reasonable. Keep it factual, not accusatory; people sometimes go quiet because of illness or a personal crisis.
- Secure your assets immediately, in parallel. Confirm you can log into the domain registrar, hosting, CMS and analytics. If you can’t, start recovery with those providers now rather than after the situation escalates. This is the step people delay and later regret.
- Pause further payments. Don’t release milestone payments for work you haven’t received and verified.
- Document everything. Keep every email, invoice, brief and deliverable in one place, with dates.
- Get an independent assessment. Have another developer review what exists. Sometimes more is complete than it appears; sometimes far less.
- Escalate proportionately. A formal written notice referencing the contract, then mediation if your contract specifies it, then small claims court for smaller amounts.
For most website-sized disputes, legal action costs more than the disputed sum — which is exactly why milestone payments and asset ownership matter more than remedies. The best protection here is structural, not legal: you control the accounts, you paid in stages, and you have documentation. Do those three things and a silent developer is a setback rather than a disaster.
Frequently asked questions
What should be included in a website design contract?
Scope of work, deliverables, timeline and milestones, payment schedule, revision limits, content responsibilities, intellectual property ownership, hosting and account ownership, confidentiality, warranty and support terms, a change-order process, and termination conditions.
Who owns the website after it is built?
You should, with ownership of the final design and custom code transferring to you on final payment. Developers typically retain rights to their own pre-existing frameworks and reusable components, while third-party themes, plugins and open-source code remain under their original licences.
How much should I pay upfront for a website?
A deposit of 30 to 50 percent is standard, with the remainder paid at milestones and the final balance due on completion before the site goes live on your domain. Paying the full amount upfront removes the incentive to finish and carries significant risk.
How many revisions should be included in a web design contract?
Two rounds per design phase is standard, plus one consolidated issue list during quality assurance. The contract should define a round as one consolidated set of feedback rather than a series of separate requests, and state the hourly rate for additional work.
What is a kill fee in a web design contract?
A kill fee is a charge payable if the client cancels the project without cause, typically 25 to 50 percent of the remaining balance. It compensates the developer for reserved capacity and work begun but not yet invoiced.
Can I get a refund if I am unhappy with my website?
It depends entirely on the contract. Most agreements make deposits non-refundable and tie payments to delivered milestones rather than satisfaction, which is why revision limits, clearly defined deliverables and milestone-based payment matter more than any refund clause.
What should I do if my web developer stops responding?
Send one written summary of outstanding deliverables with a specific response deadline, referencing your contract. At the same time confirm you control the domain, hosting and CMS accounts and begin recovery with those providers if you do not. Pause further payments, document everything, and have another developer assess the work before escalating.
Conclusion
A contract is not a sign of distrust — it is the document that lets both sides relax. The developer knows what they are building and when they will be paid; you know what you are receiving and what happens if things change.
If you read only two clauses carefully, make them ownership and payment schedule. Those two decide whether a project going wrong is an inconvenience or a genuine loss.
Our own proposals name the exclusions and hand over every account in your name, because the alternative costs us more than it saves. If you want to read one before committing to anything, tell us about the project on the contact page.