Website Project Contracts: Scope, Change Requests and Ownership

A website project contract is the document that decides what you will get, when you will get it, what it costs and who owns the result. Many small businesses sign a short quotation, assume everything obvious is included and discover the gaps halfway through the build. The most common disputes about websites are not about technology; they are about scope, delays, extra charges and ownership of files and accounts.

This guide explains the clauses that matter in a website development contract, how to write scope that cannot be misread, how to handle change requests without arguments, and what to settle about ownership, hosting and maintenance before the first invoice. It is written from the viewpoint of a business ordering a site, but developers will find the same checklist useful. It is general information, not legal advice, and a lawyer should review any contract of significant value.

Why Websites Need More Than a Quotation

A quotation lists a price for a described deliverable. A contract adds the rules for everything that happens around it: how decisions are made, what happens when someone is late, how disagreements are resolved and what each side may do with the finished work. Websites are particularly prone to misunderstandings because the deliverable is partly invisible. Two people can read “a ten-page website” and picture entirely different things: custom design or a template, written content or placeholders, a contact form or a booking system.

Projects also depend on the client as much as on the developer. Texts, photographs, logins and approvals must arrive on time, and delays on either side move the launch date. A good contract recognises this and sets out responsibilities for both parties. When the client is quick and the developer is reliable, the contract is never opened again. When the project goes sideways, it is the only thing that keeps the argument factual.

Define the Scope in Concrete Terms

The scope section is the heart of the contract. Vague wording such as “modern responsive website” invites different interpretations. Replace adjectives with lists of things that can be checked. The table below shows how to turn typical phrases into testable statements.

Also state what is not included. Exclusions prevent surprises: copywriting, photography, translation, logo design, data migration from an old system, training sessions and ongoing marketing are typical items that clients assume are included and developers assume are separate. A short “not included” list protects both sides. Our article on planning a website project from brief to launch explains how to prepare the brief that feeds this scope.

Timeline, Milestones and Payment

A timeline with dates and milestones makes progress visible. Typical milestones are design approval, content delivery, development complete, testing and launch. Link each milestone to a payment so that the supplier is paid for progress and the client pays against evidence. A common arrangement is a deposit at the start, a payment on design approval and a final payment at launch, though the split depends on the project size.

Include rules for delay. If the client does not provide content or feedback by the agreed date, the schedule moves by the same number of days, and the contract should say so. If the developer is late, specify what the client can expect: a revised date, a discount or the right to terminate after a long delay. Keep these rules proportionate; heavy penalties encourage rushed work.

• Approval periods. State how many working days the client has to review each milestone and what happens if there is no reply.
• Revision rounds. Define how many rounds of changes are included at each stage, for example two rounds of design feedback.
• Payment terms. Give due dates, accepted methods and what happens with late payment.
• Taxes. Say whether prices include or exclude VAT.

For a view of what typically drives the price, read what a website really costs.

Change Requests Without Arguments

Change is normal. A client sees the first design and wants another section; a new product line appears halfway through the build. The contract should not forbid changes but should say how they are handled. A simple process works well: the client describes the change in writing; the developer replies with the effect on price and schedule; the client approves it in writing; only then does the work start.

1. Record it. Every request goes into a shared list, by email or a project tool, with a date.
2. Estimate it. The developer gives hours or a fixed price and any effect on the launch date.
3. Approve it. The client accepts or declines. Silence is not approval.
4. Invoice it. Approved changes are billed at the agreed rate or added to a milestone.

Define what counts as a correction and what counts as a change. A correction fixes something that does not match the agreed scope, such as a form that does not send emails; it is the developer’s cost. A change adds or alters something beyond the scope; it is billed. This distinction, written down at the start, prevents most billing conflicts later.

Ownership, Licences and Files

Ownership is the clause that clients most often skip and most often regret. Several different things are involved, and each needs an answer.

• Design and code. Does the client own the custom design and code on final payment, or receive a licence to use them? Many contracts transfer ownership on full payment, but exclude the developer’s reusable tools.
• Third-party components. Themes, plugins, fonts and stock images come with their own licences. The contract should list those that are included and who pays for renewals.
• Content. The client should confirm that texts and images they supply are theirs to use, and that the developer may use them for the project.
• Domain and accounts. The domain name, hosting account and analytics should be registered in the client’s name, with the developer given access, not the other way round.
• Source files. State whether design files and the full code repository are delivered at launch.
• Portfolio use. If the developer may show the project in a portfolio, say so; if the client prefers confidentiality, say that too.

Copyright rules differ between countries, and the international framework is summarised by the World Intellectual Property Organization. Because the details vary, ask a lawyer to confirm the transfer wording for your jurisdiction. For brand assets, our guide to trademarks and brand protection explains why registering a name and logo matters before you build a site around them.

Acceptance and Testing

Decide how the site will be declared finished. An acceptance clause lists the checks that must pass before the final payment: pages match the agreed design, forms deliver messages, redirects work, the site loads acceptably on mobile and the main browsers, and there are no broken links. If accessibility matters to you, say which standard applies; the Web Content Accessibility Guidelines are the usual reference.

Give the client a fixed period to test, for example ten working days, and describe how defects are reported and fixed. Separate defects, which the developer must correct under the warranty, from new wishes, which follow the change process. Record the acceptance date in writing, because warranty periods and final invoices normally start from it. This keeps the end of the project as orderly as the beginning, and it gives both sides a clear moment at which the work is considered delivered and the relationship moves from building to running the site.

Hosting, Maintenance and Support After Launch

Launch is not the end. Sites need updates, backups, security patches and sometimes content changes. Decide before signing who does what. If the developer hosts the site, state the service level, backup frequency and what happens if you want to move. If you host elsewhere, state who deploys updates. Warranty is another important point: many developers fix defects found within a set period after launch, such as thirty or sixty days, at no charge.

After the warranty, a maintenance plan can cover updates and monitoring for a monthly fee; see what a monthly plan should include. Whatever you choose, write down response times for urgent problems, such as a site that is down, and the hours when support is available. Also record who is responsible for renewing the domain and SSL certificate, because forgotten renewals take sites offline.

Data Protection, Confidentiality and Liability

If the project involves personal data, such as customer lists, forms or accounts, the contract may need a data processing agreement. The developer may have access to information during build and testing, and you should require that they handle it securely and delete test copies afterwards. Confidentiality clauses protect pricing, strategy and unreleased products.

Liability clauses limit how much each side can claim if something goes wrong. A common approach is to cap the developer’s liability at the fees paid. Read this carefully; an extremely low cap or an extremely broad exclusion deserves discussion. Include a termination clause that explains how either side can end the project, how work completed to date is paid and how files and accounts are handed over. Our article on website handover lists what the client should receive when a site goes live. If you need a partner who documents scope, milestones and handover clearly, see our website development service.

A Short Checklist Before You Sign

Read the whole document once as if the project had gone wrong and you were looking for answers. Can you tell exactly what you will get? Are dates and payments linked? Is the change process clear? Does the contract say who owns the design, the code, the domain and the accounts? Are hosting, warranty and maintenance addressed? Are data and liability handled? If any answer is no, ask for a clause. A good supplier will not mind; clear contracts are as much in their interest as yours.

Frequently Asked Questions

Is a quotation enough for a small website?

For a very small, low-risk job it can be, if it lists deliverables, price, timing and ownership clearly. For anything larger, a contract or terms of engagement with a change process and ownership clauses is safer.

Who should own the domain name?

The business that uses the website. Register it in your name and give the developer access when needed, so you can always change supplier.

What is a fair number of revision rounds?

Two rounds per stage is common for design. More rounds can be agreed for larger projects, as long as the contract says how extra rounds are priced.

Can the developer reuse my design for another client?

Only if the contract allows it. Custom designs are usually exclusive to the client; reusable components, tools and templates the developer owned beforehand normally stay theirs.

What happens if I stop the project halfway?

The termination clause should explain payment for work done, handover of completed files and return of accounts. Without such a clause, disagreements are likely.

Do I need a lawyer to review the contract?

For high-value projects or unusual terms, yes. A short review is inexpensive compared with the cost of a dispute over ownership or liability.

The Bottom Line

A good website contract describes deliverables in testable terms, links payments to milestones, sets a simple process for changes and settles ownership of design, code, domain and accounts. It also covers warranty, hosting, maintenance, data protection and termination. Spend an hour on these points before work starts, and the project is far more likely to finish on time, on budget and with a result you control.