What to Put in a Website or App Development Contract

Scope: what will be built

Most disputes start with two people remembering different promises. The scope section should describe the work clearly enough that a third person could tell whether it was delivered. For a website that usually means the pages or page types, the features (forms, booking, shop, languages), who provides the content and images, and which browsers and devices it must work on. For a web or mobile app it means the users, the main workflows, the integrations and the platforms.

It is just as useful to write down what is not included: copywriting, photography, data migration from an old system, app store fees, third-party subscriptions. A written brief makes this much easier; our guide to writing a project brief shows what to include, and the contract can refer to it.

Milestones, payments and timing

Split the project into stages that each produce something you can see: an agreed design, a working staging site, a first version real users can try, the launch. Tie payments to those stages rather than to dates alone, so both sides are paid for, and receive, finished work.

Write down what each side must provide and by when. Timelines often slip because content, logins or feedback arrive late, and the contract should say how the schedule moves when that happens. Our guide on how long a website takes explains the usual stages.

Acceptance: how you agree it is done

An acceptance clause turns "finished" into a procedure. It typically says:

• where you will review the work, for example a private staging site;
• how long you have to test it and report problems;
• what counts as a defect (it does not do what the scope says) as opposed to a new idea;
• how quickly defects are fixed and re-tested;
• what happens if you neither accept nor report problems within the review period.

Agreeing these steps in advance keeps the end of the project calm. Our website launch checklist is a useful list of things to test before you accept. If accessibility matters to you, name the WCAG version and level the work must meet; our guide to website accessibility laws explains which standards the main laws refer to.

Change requests

Plans change once people see real screens, and that is healthy. The contract should say how a change is handled: you describe it, the developer says what it does to cost and timing, and nothing is built until you agree in writing (an email can be enough if the contract says so). Without this, small additions pile up and nobody is sure what the budget covers. If you want room to learn as you go, agree a smaller first version and plan the rest after it is in use; our guide to scoping a first version explains how.

Who owns the work: copyright and source code

This is the clause people most often assume rather than check. Paying for work does not by itself make you the owner of the copyright in it.

In the UK, the IPO's guidance on ownership of copyright works says that when you commission someone to create a copyright work, "the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing". If the contract is silent, the IPO notes, a court may find only an implied licence to use the work for its purpose, which "does not necessarily result in a transfer of ownership". It even uses a website built jointly by a freelancer and a company employee as an example of joint ownership.

In the US, the Copyright Office's Circular 30, Works Made for Hire explains that a commissioned work counts as "made for hire" only if it falls into one of nine listed categories and both parties sign a written agreement saying so. Work by an independent developer often does not fit those categories, so ownership is usually moved by an assignment instead. Circular 1, Copyright Basics says a transfer of copyright "generally must be made in writing and signed" by the owner, and that owning a copy of a work does not mean owning its copyright.

So the contract should state, in plain words:

• who owns the copyright in the custom code, design and content created for you, and from when (often on full payment);
• that you receive the source code, not just a working site or app, and where it will be kept (for example a repository in your organisation's account);
• which parts the developer keeps and licenses to you, such as reusable code libraries they use on every project;
• which third-party and open-source components are used, and that their licences allow your use.

Accounts, domains and hosting in your name

Ownership of the code helps little if you cannot reach it. Ask for the key accounts to be registered to your business, with the developer added as a user: the domain name, hosting, DNS, the code repository, analytics, email sending services, payment providers, and for apps the Apple and Google developer accounts. Our guides on domain names, web hosting and publishing to the app stores explain what each account is. The contract should also say who pays for each service after launch.

Warranty, support and maintenance

Separate two things. A warranty period covers defects in the work as delivered: for a set period after launch, the developer fixes things that do not match the agreed scope at no extra cost. Support and maintenance is ongoing work: software updates, security patches, backups, monitoring and small changes. It is usually a separate agreement with its own price, response times and list of what is included. Write down which of the two applies to what, and what happens to updates if you decide not to take a maintenance plan.

Personal data and confidentiality

If the developer will see or host personal data, such as customer records, form entries or orders, data protection law applies. Under the UK GDPR, a supplier that processes personal data on your behalf is a processor, and the ICO's guidance on what a controller-processor contract must include lists the minimum terms set by Article 28(3): processing only on your documented instructions, confidentiality, appropriate security, rules on sub-processors, and what happens to the data when the contract ends, among others. Include confidentiality for your business information as well, and agree how logins and passwords are shared (through a password manager, not plain email). Our guide to website privacy basics covers the public-facing side.

Ending the contract and handover

Agree at the start what happens if the project stops early or the relationship ends later: what you pay for work done so far, and what you receive, including the source code, design files, credentials, documentation and a database export. A clear handover clause makes it easy to move to another developer or bring the work in-house, and protects both sides.

When you compare developers, how they answer questions about these clauses tells you a lot. Our guide to choosing a web developer has more questions to ask.

Frequently asked questions

Do I own the website or app I paid for?

Not automatically. UK IPO guidance says the creator is the first owner of copyright in commissioned work unless you agree otherwise in writing, and the US Copyright Office says a transfer of copyright generally must be in writing and signed. Put ownership in the contract.

Is a website a work made for hire in the US?

Only in limited cases. Work by an employee in the course of their job is. Commissioned work by an independent developer counts only if it fits one of nine listed categories and both sides sign a written agreement, so ownership is usually transferred by an assignment instead.

Should I get the source code?

Yes. Ask for the source code, design files and documentation to be delivered, ideally into a code repository your business controls, so you can move to another developer or bring the work in-house.

What is the difference between a warranty and a maintenance plan?

A warranty covers defects in the work as delivered for a set period after launch. Maintenance is ongoing work such as updates, security patches, backups and small changes, usually agreed and priced separately.

Is this guide legal advice?

No. It explains common contract topics and official guidance in general terms. Laws differ between countries, so have a lawyer review any contract before you sign it.

Planning a project? See how we run website, web app and mobile app projects, see all our services, or email info@creahive.com.