The quote is agreed and the developer says they will “send something to sign”. What arrives is either a single page that mostly talks about payment, or a long template downloaded from somewhere that mentions software licences you have never heard of. You are about to put a real amount of money into this, and you would like the paperwork to protect you without turning a small project into a legal one.
For a small business site, a website development contract can be short. Its job is to settle, in plain language, the questions that cause disputes when nobody answered them at the start. Below is what to put in a web design agreement, clause by clause, with example wording you can adapt. This is general information, not legal advice. For a large project, or anything unusual, have a lawyer read the final version.
Why a short written agreement beats a handshake
Most disagreements between site owners and developers are not about bad faith. They are about two people remembering a conversation differently. Was the blog included? Who was supposed to write the service pages? Does “support” mean fixing a broken form or adding a new page? Writing the answers down before work starts costs an hour and saves a falling-out.
The contract should match the quote. If the quote already sets out pages, features and price in detail, the agreement can refer to it (“the scope in Quote 14 dated…”) instead of repeating it.
The parties and the project
Names, addresses and, where relevant, registration or GST details of both sides. Then one short paragraph describing the project in words you both recognise.
Example: “The Developer will design and build a five-page business website for the Client on WordPress, as described in the attached scope.”
Scope, and how changes are handled
Attach or reference the page list and feature list. Then add a short change clause, because something will change.
Example: “Work not listed in the scope will be quoted in writing before it starts. The Client may accept or decline each quote. Accepted changes may affect the delivery plan and the final amount.”
If you have prepared a requirements document for the site, attach it as well, so both sides can point to the same description of what was asked for.
Responsibilities on each side
Most contracts list what the developer does. Fewer list what the client does, and that is where delays come from. Put both in.
- Developer: design, build, testing on agreed browsers and devices, setting up the site on the agreed hosting, launching it on the domain.
- Client: supplying final text, images and logo; giving feedback in one consolidated list per round; providing access to domain and hosting; naming one person who approves.
This is also where to say who writes content, who sources photos, and who sets up third-party accounts such as a payment gateway or business email.
Payment terms
State the total, how it is split, what each payment is tied to, how invoices are issued and how long either side has to pay. Tying payments to approved stages rather than dates is usually fairer, and we cover the common structures in a separate piece on advance and milestone payments. Add a line on what happens to late payments and whether work pauses until they are cleared.
Ownership of the website
This is the clause owners are most likely to regret skipping. Spell out who owns what once the final payment is made.
- Your content: text, photos, logo and data you supplied remain yours throughout.
- The finished site: the design, the custom code and the built pages pass to you on full payment.
- Third-party items: themes, plugins, fonts and stock photos are licensed, not owned. The contract should say whose name each licence is in and that it transfers or is bought in yours.
- Developer’s own tools: reusable code the developer uses across many projects may stay theirs, with you granted a permanent licence to use it on your site.
Example: “On receipt of full payment, the Client owns the completed website and all custom design and code created for it, excluding third-party components, which are licensed to the Client under their own terms.”
Domain, hosting and access
Write down that the domain is registered in your name and the hosting account is yours, or that both will be transferred to you on completion. Also that you will receive administrator access to WordPress and full access to hosting. If you are unsure what the two are, our explanation of the domain versus hosting difference covers it.
Developers sometimes register these for convenience. That is fine if the contract says they are held for you and will be handed over, including the registrar login, not just the DNS settings.
Review, acceptance and launch
Define how the site is checked before it is called finished. A practical version:
- The developer shares a preview link once all scoped pages are built.
- The client sends one consolidated list of issues.
- The developer fixes items that are within scope; anything new is treated as a change.
- A stated number of rounds is included; further rounds are charged at an agreed rate.
- Acceptance happens when the client confirms in writing, or after an agreed period with no reply.
The difference between “this does not work as agreed” and “I would now like it different” should be written in plain words, because that is where most end-of-project arguments sit.
Post-launch fixes and support
Say whether there is a period after launch during which the developer fixes defects in their own work at no charge, how long that period is, and what counts as a defect. Problems caused by later plugin updates, changes made by others or hosting issues are usually excluded, and it is better to say so.
Ongoing maintenance, if any, is normally a separate arrangement. Our note on maintenance contract terms covers that agreement, which has different concerns from a build.
Confidentiality and portfolio use
A short clause saying each side keeps the other’s business information private is sensible. Separately, decide whether the developer may show your site in their portfolio or add a credit link in the footer. Many owners do not mind; some do. It is simpler to agree now.
Ending the agreement early
Either side should be able to end the contract with written notice. The clause should then cover:
- Payment for work completed up to that point
- Refund of any payment for work not done
- Handover of files, access and licences bought for the client
- Return or deletion of each other’s confidential material
It feels pessimistic to write this, but projects stop for ordinary reasons, and a clean exit clause keeps an ending from turning into a dispute.
Limits, disputes and which law applies
Larger agreements include a limit on liability, often tied to the contract value, and a clause on how disputes are handled: first by discussion, then perhaps mediation, then the courts of a named place. If you and the developer are in different countries, naming the governing law matters more. These clauses are exactly where a lawyer’s advice is worth paying for, and we would not suggest wording for them here.
Reading a website development contract the developer sent you
Often the developer supplies the document and you are the one reviewing it. Read it with the quote open beside it. Every page and feature in the quote should be covered, either listed in the contract or referenced by quote number. Then look for what is missing rather than what is there: client responsibilities, ownership, domain and hosting, acceptance, and the exit clause are the usual gaps.
If a clause is unclear, ask for it to be rewritten in plain words. A developer who wrote it themselves will usually be happy to clarify; one who copied a template may not know what it means either, which is worth discovering now. Keep the signed copy, the quote and any written changes together in one folder.
Things that do not belong in a small site contract
- Promises about search rankings, traffic or sales. No developer controls those, and a clause that implies otherwise is a warning sign.
- Penalties so heavy that no reasonable developer would sign.
- Long software-licensing templates written for enterprise products.
- Automatic renewal of services you did not ask for.
A one-page checklist before signing
- Scope attached or referenced, with a change process
- Client responsibilities listed, including content and approvals
- Payments tied to stages, with invoices for each
- Ownership on full payment, and licences in your name
- Domain and hosting in your name, admin access promised
- Review rounds and acceptance defined
- Post-launch fix period and what it covers
- Confidentiality and portfolio permission
- Exit clause with handover
- Governing law and dispute route, checked by a lawyer if the project is large
A contract like this is a page or two, and a careful developer will not object to any of it. If you are still weighing up budgets before you reach the signing stage, our guide to website making cost in India explains what drives the number you will be agreeing to.
