The most expensive sentence in a website contract is the one that is not in it. I see it every time I take over a site from another developer: the site is up, it looks respectable, and nobody can answer who actually owns the code, whose account the plugin licences were bought on, or where the repository lives. The document signed two years earlier says nothing about any of it, because it was a three-page shell about the subject matter of the agreement and force majeure. So when someone goes looking for a website build contract template, they are usually not after a legal shell - they are after certainty that once the project is handed over, they will be left with a working site and the full set of keys to it.
I look at this from the developer’s side of the table, since building company sites and stores is what I do for a living. One thing up front: this is not legal advice and I am not pretending to be a lawyer. I am only talking about what has to be in the document for a project to be accepted, settled, and if need be moved to somebody else. The form of a copyright assignment, contractual penalties and liability for personal data are for a lawyer to read before you sign anything.
Seven points that protect the client
Before the detail, a short checklist. If the document on your desk is missing any of these, it is not really a build contract yet - it is an invitation to a later conversation about what both sides meant.
- Scope as an appendix, broken down into pages and features, rather than a single line in the subject-matter clause.
- Deadlines that openly depend on you - the developer waits for copy, photos and decisions, so the clock has to start when those arrive, not on the day of signing.
- Milestones tied to payments, so neither side ends up financing the other through the whole project.
- An acceptance procedure - who reviews, within what time, how many rounds of revisions are included, and what happens to remarks raised after sign-off.
- Assignment of rights to whatever was made to order, with the moment of transfer named.
- A warranty on defects after launch - a window in which you fix faults rather than build features, with no extra invoice.
- An exit package: code, credentials, information about licences, and a short note on whatever is unusual about this particular site.
The rest of this article expands the four points that derail the most projects in practice.
Scope as an appendix - the one part no template can write for you
The formal shell of a contract is interchangeable: parties, subject, fee, withdrawal, confidentiality. Scope is not interchangeable, because it describes your site specifically and nobody will write it for you.
The difference between a good and a bad scope clause looks like this:
- Building a company website including deployment - means nothing. There is no way to tell from it whether the site has a blog, whether a newsletter form is included, or how many pages there even are.
- A WordPress site: sixteen pages listed in the appendix, a blog with categories, a contact form with notifications to two addresses, an English version as a separate URL tree, WCAG conformance at level AA - means exactly as much as it says, and after handover you can see whether it happened.
That appendix is not written while signing the contract. It comes earlier, when the scope itself is being settled. I wrote up separately what belongs in it and what an honest developer asks about unprompted, in the piece on what a good website brief contains; that one covers the substance, here I care only about moving it into the document.
The second sentence almost nobody has: what falls outside the scope. Copy and translations, photos and the licences for them, blog posts, migrating old content, training the team, buying premium plugins, hosting and the domain. This is not a developer narrowing their commitment, it is both sides being spared a conversation at the worst possible moment - two days before the planned launch.
Deadlines, milestones and payments - who is waiting on whom
The most common cause of delay in the projects I run is not the code. It is that copy and photos arrive later than agreed, and the decision between two homepage directions waits for a board meeting. That is normal, and a contract can describe it honestly instead of pretending the developer works in a vacuum.
A sensible clause does three things. First, it splits the project into stages - scope and architecture, design, build, testing and launch. Second, at each stage it says what it needs from you, and what happens to the deadline if that does not arrive on time. Third, it ties payments to stages rather than to the calendar.
Paying for the whole project up front is bad for you, because all your leverage disappears the day the transfer clears. Paying entirely on completion is bad for the developer, who on a larger project finances your company for months, and the first cash-flow squeeze ends the job. Splitting the fee into instalments attached to completed stages solves both, and gives you natural checkpoints along the way: if stage two looks wrong, you do not pay for stage three.
One thing worth spelling out: who pays for a change of scope mid-project. The point is not to penalise new ideas, because they always turn up, but to establish that work beyond the agreed scope does not start without written acceptance of a price and a new date. That clause mostly protects you - without it, an invoice can arrive for work nobody knowingly ordered.
Copyright, code and credentials - what has to be written down
This is the most important part of a website contract and, at the same time, the part ready-made templates essentially never have. Three things need to be named plainly.
First, rights to whatever was made to order. The design, a custom theme, the features written for you, the configuration - the contract has to say that rights to these pass to you, and at what moment. Market practice ties that transfer to payment of the full fee, and it is a fair arrangement for both sides. Note that a copyright assignment needs to be in writing and needs to state what exactly you are acquiring rights to, so this is the fragment a lawyer has to read. A line saying the client receives full rights to the site reads well and does not do the job.
Second, the code nobody transfers, because they cannot. WordPress, most themes and most plugins are licensed under the GPL - they do not belong to your developer and cannot be assigned to you. That is not a problem, it is a reason for the clause to be precise: rights to the part written to order, plus delivery of a complete, runnable copy of the whole thing. A copy any other developer can stand up on their own machine without asking the previous one for anything. If the work lives in a repository, the contract should say you get access to it or a full copy of it.
Third, whose accounts these are. The domain, hosting and third-party service accounts registered to you, with access granted to the developer - never the other way round. A domain registered to the developer is the most expensive kind of convenience I know. For paid plugins, the contract should name whose account the licences are bought on and who renews them after launch, because a licence sitting on the developer’s account stops working the day you part ways. How this plays out afterwards, under an ongoing arrangement, I covered in the piece on the website maintenance contract.
Acceptance, revisions and warranty - when the site is finished
Without an acceptance procedure a project never ends, it just gradually goes quiet. The contract should answer four questions: who signs off on your side, within what time from the notice of readiness, in what form remarks are raised, and how many rounds of revisions are included.
That last point gets read as distrust of the client, and it is the opposite. A contract with no revision limit does not give you unlimited revisions - it gives the developer a reason to price the risk in, or to stop replying around the sixth round of button-colour changes. A stated number of rounds plus a rate for further ones is predictable for both sides.
Warranty sits separately from revisions, and the two need to be kept apart in the document. Revisions are about the result not matching what was agreed. A warranty is about defects that surface after launch: the form not sending mail in one browser, the menu breaking on a specific phone, something failing after an update the developer themselves applied. The contract should state how long that warranty runs and say outright what it does not cover - new features, content changes, the consequences of installing plugins yourself, and outages on the hosting side. A warranty is not the same thing as ongoing care; that is a separate service with a separate cost, worth pricing before launch rather than after.
What not to sign
A few clauses that make me stop reading and ask a question:
- No handover of code and credentials. A site you cannot reach at the file and database level is not yours in any practical sense.
- A licence instead of an assignment of rights, especially a revocable one or one tied to a subscription fee. At that point you are not buying a site, you are renting it indefinitely.
- A site on the developer’s closed platform with no clause on exporting content and moving it. Leaving that arrangement costs a second build.
- A deadline without a date - promptly, as far as possible, after materials are delivered, with no statement of how long the clock then runs.
- A fee with no scope, meaning an amount and a date but a vague line about building a website instead of an appendix.
- A ban on handing the project to another developer, or a requirement to get the current one’s consent. There is no justification for that beyond blocking the door.
- No warranty at all. A developer unwilling to stand behind their own workmanship even briefly does not believe in what they are delivering.
None of these necessarily signals bad faith - some of these templates have been circulating for years and people sign them by reflex. Which is why choosing the developer matters more in practice than choosing the template; what to look at while choosing, I covered separately in the piece on who can build your company website.
What a ready-made template usually leaves out
Ready-made documents circulate under plenty of names - website development agreement, web design contract, website build contract template - and as a starting point they are fine. Their formal shell is usually correct, because that is the easy part. Everything else consists of things a universal template cannot contain, because they are specific to your project.
What such templates most often lack:
- The scope appendix - there is a line about building a website, there is no list of pages and features.
- A link between the deadline and your materials, which leaves the date either fictional or impossible.
- Stages and instalments matched to how the project actually runs.
- A precise rights clause that accounts for part of the code being open-licensed.
- An acceptance procedure with a number of revision rounds.
- An exit package - who hands over code, credentials, licence information and documentation.
A practical way to work with a template: take the shell, throw out the generalities about professional execution, and add appendix one with the scope and appendix two with stages, dates and instalments. Two pages added to a template do more than ten pages of clauses - and the answer to whether you need a lawyer is: not for those two appendices, yes for the clauses on rights and liability.
How I handle it
I work fixed-bid, so the scope, the price and the date go out together, in writing, before anything is signed - the estimating risk is mine, not yours. On top of that comes what I consider the minimum of fair dealing: the list of pages and features as an appendix, stages with instalments, a clear statement of which materials I am waiting on, assignment of rights to whatever I wrote to order together with the final payment, and delivery of a complete, runnable copy of the site along with the credentials. When I build a company site from scratch or rebuild an existing one, that same scope appendix later doubles as the checklist at handover.
If you have a contract from a developer in front of you and you are not sure what is missing, send it over along with a description of the project. I will tell you which of the points above it already covers and which it does not, before you put your name to it.
Frequently asked questions
Does a website build contract have to be in writing? The working relationship itself usually does not require written form, but a copyright assignment does - and that is the main reason for the document to exist at all. Without it you are left with a finished site and no clarity about what you may actually do with it. Confirm the form and legal effect of specific clauses with a lawyer; I look at this from the technical side.
When do the rights to the site pass to the client? In a well-written contract, on payment of the full fee, stated outright along with what the rights cover. Watch for two shortcuts: handing over the files does not by itself transfer rights, and the open-licensed part, such as WordPress or typical plugins, is not transferred by anyone - what counts there is the right to the code written to order plus a complete, runnable copy of the whole.
Is the post-launch warranty the same as ongoing care? No. A warranty covers defects in workmanship from the project itself, while care means routine updates, backups, monitoring and small changes after launch - a separate service under a separate agreement. It is worth pricing before the site goes live; I broke that down in the piece on website maintenance costs.
Need something like this on your side? I design and build websites for B2B companies - from scratch or as a rebuild of what already stands. Let’s talk about your project.