Web Design Contracts: The 7 Clauses Every SMB Should Insist On

A web design contract is the document that decides whether the site you paid for is actually yours when the project ends. Most small and mid-sized businesses read the quote carefully and skim the contract, which is exactly backwards. The most important web design contract clause is intellectual property transfer on full payment, because without it the agency that built your site is the legal owner of the design and the code, no matter how much you paid. Everything else in the contract protects you from inconvenience. The IP clause protects you from losing the whole asset.

After delivering more than two hundred and fifty websites, we have seen the contract go wrong in every direction. We have seen businesses unable to move hosts because the domain was registered in the agency's name. We have seen a company pay a five-figure invoice and then discover it had bought a licence to use its own website rather than ownership of it. None of this happens because agencies are villains. It happens because nobody wrote the boring parts down, and the boring parts are where the value lives. This article walks through the seven clauses that matter, with short examples of the kind of language you should expect to see. One thing first: this is not legal advice. It is a guide to what a sensible web agency contract should contain so you know what you are reading. Before you sign anything, have a solicitor review the actual document.

Why the Contract Matters More Than the Quote

The quote tells you what something costs. The contract tells you what you are buying, what happens when the project drifts, and what you walk away with. Those are bigger questions, and they are the ones that come back to bite people two years later when the relationship with the original agency has ended and the site needs to move.

Here is the pattern we see most often. A business chooses an agency on price and personality, signs a short contract without much thought, and the project goes fine. Eighteen months later they want to switch agencies, redesign, or simply move hosting. That is the moment the contract gets read properly, and that is the moment people discover what they did not negotiate. The good news is that fixing this is free. It costs nothing to ask for the right clauses before you sign. It costs a great deal to be missing them afterwards.

There is also a quieter benefit to a thorough contract that is easy to overlook. A document that spells out ownership, handover, warranty, and exit terms forces both sides to have the awkward conversations early, while everyone is still optimistic and reasonable. A vague contract simply postpones those conversations until something has gone wrong, when goodwill is lower and positions have hardened. A good web design contract is not a sign of distrust between client and agency. It is the thing that lets a relationship survive the disagreements that every project eventually produces, because the answers were agreed before anyone had a reason to argue about them.

Clause One: IP Transfer on Full Payment

This is the clause that matters most, so it is worth being precise about why. Under copyright law in the UK and most comparable jurisdictions, the person who creates a work owns the copyright in it by default. That means the agency that designs and codes your website owns the design and the code unless it assigns those rights to you in writing. A friendly verbal assurance that the site is yours has no legal weight. The assignment has to be a written term in the contract.

The clause needs to do two things. It needs to state that ownership transfers, and it needs to name what transfers, because a vague clause invites a narrow reading. You want the design files, the custom code, and the arrangement of content all explicitly included. Be alert to the word licence. A licence is permission to use something, not ownership of it, and a licence can be limited, non-transferable, or revocable. You are not paying for permission. You are paying for an asset. The transfer should also be tied to full payment, which is fair to both sides: the agency keeps leverage until it is paid, and you get clean ownership the moment you settle the final invoice.

A reasonable version reads:

Upon receipt of final payment in full, the Agency assigns to the Client
all intellectual property rights, including copyright, in the deliverables
created under this agreement, comprising the website design, custom code,
and the arrangement of content.

Clause Two and Three: Source Files and Training Handover

Owning the intellectual property is necessary but not sufficient. If you own the rights to the code but only ever receive a live website with no way to export it, your ownership is theoretical. So the contract needs a source-file delivery clause that lists what you receive and when. That means the editable design files, the theme and any custom plugin source code, original images and assets, and where relevant a database export. Put a deadline on it. Something like delivery within ten business days of final payment turns a vague promise into an obligation. The failure mode here is the agency that hands over a login and nothing else, leaving you unable to take your own site anywhere.

The third clause is training and handover hours, and it is the one most often skipped because it feels soft. It is not soft. Without a named amount of training, you are dependent on the agency for every content change forever, and that dependency is sometimes deliberate. A good clause specifies the hours, the format, and ideally that the session is recorded so new staff can be brought up to speed later. A short version reads: "The Agency will provide three hours of recorded training covering content editing, plugin updates, and backup verification, together with a written handover document." Three hours and a document is the difference between owning a website and renting a relationship.

Clause Four: Post-Launch Warranty Period

No website launches perfectly. Something will break in the first few weeks, and the contract should say clearly who pays to fix it. A post-launch warranty clause defines a window, commonly between thirty and ninety days, during which any defect that was present at launch is corrected at no cost to you.

The important detail in this clause is the distinction between a bug and a change. A bug is something the agency built that does not work as specified, a broken contact form or a layout that collapses on mobile. A change is something that works correctly but that you have now decided you want differently. The warranty covers bugs. It does not cover changes, and a well-written clause says so plainly, because that boundary is where disputes start. Defining it in advance protects both sides. You get free correction of genuine faults, and the agency is not pressured into doing unpaid redesign work under the banner of bug fixing.

Reasonable language:

For sixty days following launch, the Agency will correct, at no additional
cost, any defect in the delivered work that deviates from the agreed
specification. Requests for new features or changes to agreed functionality
are not covered by this warranty and will be handled as change orders.

Clause Five: Hosting and Access Ownership

This is the clause that catches more SMBs than any other, and it has nothing to do with code. It is about accounts. Your domain name, your hosting account, your DNS settings, your content management system admin, your analytics, and any email accounts created for the project all need to be registered in your name or transferred to you at handover. The classic hostage situation is the agency that registers the domain in its own name as a convenience at the start of the project. That convenience becomes a problem the day you want to leave, because the agency, not you, controls the single most important asset in your online presence.

The clause should require that all accounts are either registered to the client from the outset or transferred to the client at project handover, with administrator-level credentials provided. Administrator level matters. A standard user account that the agency can revoke is not ownership. You want the keys, not a borrowed set. If an agency resists this, treat it as a serious warning sign rather than a minor administrative quibble.

Clause Six and Seven: Change Orders and Exit Terms

Scope changes are normal on almost every project, so a sensible web agency contract plans for them rather than pretending they will not happen. A change-order clause pre-agrees the day rate and the process for anything outside the original scope. Agreeing the rate up front means a mid-project request does not turn into an awkward renegotiation, and requiring written approval before work begins protects you from surprise charges. A clean version reads: "Work outside the agreed scope will be quoted as a change order and billed at the rate of GBP [rate] per day, with written client approval required before that work begins." That single sentence removes most of the friction that builds up during a project.

The seventh clause is exit and termination, and it is the one nobody wants to think about while signing. It should cover what happens if either party ends the engagement: the notice period required, payment for work completed up to that point, who keeps which assets, and the agency's handover obligations on termination. The point of this clause is simple. If the relationship ends halfway through, for any reason, you should not be stranded with a half-built site, no files, and no clear path forward. A fair termination clause means a bad relationship can end without becoming a disaster. It is insurance, and like all insurance it feels unnecessary right up until the moment it is the only thing protecting you.

What to Do Before You Sign

Read the contract before the quote, not after. Check that all seven of these clauses are present and specific, and be wary of vague wording, because vague wording is interpreted by whoever wrote it. If a clause is missing, ask for it. A reputable agency will add these terms without hesitation, because a reputable agency expects to be asked and has nothing to lose by agreeing. An agency that pushes back hard on IP transfer, source-file delivery, or account ownership is telling you something important about how the relationship will go.

To say it once more clearly: this article is a guide to understanding a web design contract, not a substitute for legal advice. The example phrasing here is meant to show you what good terms look like, not to be copied into a binding agreement. Have a solicitor review the actual contract before you sign it. The cost of that review is small, and it is the cheapest insurance you will buy on the whole project.

At WitsCode, all seven of these clauses are part of our standard web agency contract rather than something a client has to think to ask for. Intellectual property transfers to you on final payment, source files and full administrator access are handed over as a matter of course, and the training and warranty terms are written in plainly. We do it this way because in more than two hundred and fifty projects we have learned that a clear contract is not a constraint on a good relationship. It is what makes a good relationship possible. If you would like to talk through what a fair contract for your project should look like, we are happy to walk you through ours clause by clause before you commit to anything.