What a website development contract should include

A website development contract should include a scope that lists the deliverables, milestones with acceptance criteria, payment terms tied to those milestones, a clear statement that you own the domain, the content and the code, a limit on revisions, a defined support period after launch, and a termination clause that lets either side leave cleanly. Most disputes between clients and studios trace back to one of those seven being vague or missing.

This post explains what each clause should say and why. It is written from the studio side, and it is not legal advice. Have a lawyer in your jurisdiction review any contract before you sign it; the cost is small against the cost of the project.

What should the scope section say?

The scope is the list of what you are buying. It should be specific enough that a third person could check each item off at launch.

• The pages, by name, and which are templates used more than once.
• The features, by name, with a line on what each does: "contact form with fields X, Y, Z, sending to address A, with spam protection".
• The platform and hosting arrangement.
• The content: who writes copy, who supplies images, what happens if content is late.
• The design process: how many concepts, how many rounds of revision at each stage.
• What is excluded: copywriting, photography, paid plugins, third-party subscriptions, ongoing SEO work, anything the studio does not do.

A good website brief becomes most of this section. If the studio's proposal describes the scope well, the contract can refer to the proposal by date and version and attach it.

Then the change process. The clause should say that work outside the scope is a change request, priced in writing, approved by you before it starts, with the effect on the timeline stated. This protects both sides: you from surprise invoices, the studio from unpaid work. Our post on fixed price versus hourly covers how change requests work under each model.

How should milestones and payments be structured?

Milestones are the points where work is reviewed and money changes hands. Each one needs an acceptance criterion: what "done" means for that stage.

The shape varies, and a studio quoting website design and development will have its own version. What matters is that payments follow deliverables, not calendar dates, and that each deliverable has a definition. "Design approval" with no definition becomes an argument about whether a second round of changes is approval or a revision.

Payment terms should also say the invoice due period (7, 14 or 30 days), what happens on late payment, and whether tax is included. In India, GST applies to web development services; the contract should state whether figures are inclusive or exclusive and show the registration number. Check with your accountant on how it applies to your business.

Add a clause on what happens if you go quiet. Projects stall when a client cannot give feedback for six weeks. A fair clause lets the studio pause the project after a stated period of silence and resume with a rescheduled timeline, sometimes with a fee. It is reasonable and it protects your project from losing its place in the queue.

Who owns the domain, the content and the code?

You should, and the contract should say so in three separate lines, because they are three separate things.

The domain. Registered in your name, at a registrar where you hold the account. The studio may manage DNS with delegated access. ICANN publishes the rights and responsibilities of domain registrants, and the one that matters here is that the registrant of record controls the domain. If a studio registers your domain under its own account, you do not own it in any practical sense.

The content. Your copy, images, logo and brand stay yours. Anything the studio writes or produces for the site transfers to you on final payment. Stock images and fonts stay under their own licences, and the contract should list any with a recurring cost.

The code. The custom code transfers to you on final payment, usually as a repository you own or have been given full access to. Third-party components, such as WordPress plugins, open-source libraries and frameworks, stay under their own licences, and you get the right to use them. The studio may keep the right to reuse general techniques and its own internal tooling, which is normal and does not affect your site.

Two more lines belong here. The hosting account should be in your name, with the studio as a manager, so you can leave without a migration. And the contract should state that the studio will hand over all credentials, repository access and documentation at the end, whether the end is launch or termination.

If a studio pushes back on any of this, ask why. There are honest reasons to keep a licence to reusable components the studio brings to every project. There are no honest reasons to keep your domain.

How many revisions, and what counts as one?

Unlimited revisions is a promise nobody keeps. A fair clause states the number of revision rounds at each stage, typically two or three at design and one or two at build, and defines a round as a consolidated set of feedback from the client's designated approver.

Define what a revision is and is not. Moving sections, changing colours, adjusting copy and swapping images within the approved design are revisions. A new page, a new feature or a redesign of an approved page is a change request. Without that line, the third round of "small changes" that adds a careers section is an argument.

Name the approver. One person at your company gives feedback and approval. Feedback from five people in three email threads is how projects double in length.

What support comes after launch, and for how long?

Two separate things, and the contract should treat them separately.

Warranty. A period after launch, typically 30 to 90 days, in which the studio fixes bugs in the work it delivered at no charge. A bug is something in scope that does not work as specified. A new request is not a bug. The clause should say how to report a bug and how quickly the studio responds.

Ongoing support. An optional care plan for updates, backups, monitoring, security and content changes, with its own scope and monthly price. It should be a separate agreement or a clearly separate section, and it should not be a condition of the build contract. See how much website maintenance costs for what the plan should cover and what it should cost; our own website care and maintenance scope is a reasonable checklist.

The contract should also say what the studio hands over if you do not take the care plan: documentation, credentials, a walkthrough for your team. You should be able to take the site to another provider without needing the original studio's cooperation.

How can either side end the contract?

A termination clause lets both sides leave with the work done so far paid for and handed over. A fair one says:

• Either side can terminate with written notice, usually 14 to 30 days.
• You pay for work completed to the date of termination, calculated against the milestones or at an agreed rate.
• The studio hands over everything produced to that point, in a usable form, within a stated time.
• Any deposit is applied against work done, with the balance refunded or invoiced.

Add a clause for the studio's failure to deliver: if a milestone is missed by more than a stated period for reasons within the studio's control, you can terminate and recover the deposit for incomplete work. And a clause for your failure to respond, as covered above.

Avoid contracts with no exit, or where leaving forfeits everything paid. Projects fail for reasons that have nothing to do with bad faith, and both sides need a way out that does not involve lawyers.

What else belongs in the contract?

Shorter clauses that still matter.

• Confidentiality. Both sides keep business information private. The studio may show the finished site in its portfolio unless you say otherwise; decide now.
• Timeline. Start date, milestone dates, and what shifts them: late content, late feedback, change requests.
• Third-party costs. A list of subscriptions, plugins and services the site needs, who pays, and whose account they are on.
• Accessibility and performance targets. If the brief asked for Core Web Vitals or an accessibility standard, write it in as a deliverable, not an aspiration.
• Liability. A cap on the studio's liability, usually the contract value, and a statement that neither side is liable for lost profits. Lawyers care about this one; let yours read it.
• Governing law. Which country's law applies and where disputes are heard. For a client in Dubai and a studio in India, this needs an answer before signing, not after.

Take this list and the studio's draft to a lawyer. Thirty minutes of their time on a $10,000 contract is cheap, and they will catch the clause that this post, written by a web studio and not a law firm, did not think of. For the figures to check the price against before you get there, read how much a website costs; for how to run the project after signing, the project timeline estimator turns the phases above into a rough schedule.