Who Owns the Code? Ownership, Hosting and Exit Clauses for a Website Contract

The question almost nobody asks during a website procurement is the one that decides how the relationship ends. Not what the site will look like, or what it costs, but who owns it afterwards — and what you are actually able to take with you if you leave.

It rarely matters while things are going well. It matters enormously at exactly the moment you have least leverage: the agency has been acquired, the relationship has soured, the price has gone up, or the person who understood your site has left. Organizations discover these clauses when they need them, which is too late to negotiate them.

Here is what to settle in the RFP, before anyone has been selected and while you still have every bidder's attention.

Ownership of the work you paid for

Say plainly that all deliverables — source code, designs, configuration and content — are assigned to you on final payment.

Two details do most of the work. On final payment protects the supplier, which is why it is a reasonable ask rather than an aggressive one; no agency should hand over the assets before being paid, and saying so makes the clause easy to accept. And assigned rather than licensed is the distinction that matters: a licence can be revoked, limited to particular uses, or made conditional on continuing to pay for something else.

The common failure mode is silence. Where the contract says nothing, the default position varies with jurisdiction and circumstance and is frequently not what the client assumed. Do not rely on it being obvious that you own something you commissioned and paid for.

Proprietary components, which is where it gets complicated

Full assignment is a clean idea that meets a messy reality: almost no agency builds everything from scratch. Your site will contain open source libraries, commercial plugins, licensed fonts, stock photography, and often the agency's own internal framework or component library.

You cannot be assigned ownership of any of that, and a supplier who agrees to assign it is either misunderstanding the question or making a promise they cannot keep. What you can require is disclosure and a durable licence.

Ask every bidder to list any proprietary or third-party component their build will depend on, with its licence terms and its annual cost. Then require, in the contract, a perpetual licence to keep using each one on this site, with or without them, and clarity on who pays for renewals.

The answer to this question is genuinely informative when you are still choosing. A vendor who says the site will run on their own proprietary framework, licensed annually and only supported by them, has told you the site is not portable. That may still be the right choice — proprietary platforms often have real advantages — but it should be a decision you made rather than one you discovered.

Fonts and photography, quietly

Licensed typefaces and stock images are the two assets most often transferred informally and least often documented. A web font licence is typically tied to a domain and a pageview tier, and it may have been bought on the agency's account. Stock photography is usually licensed to the purchaser, not to you, and licences vary in whether they can be transferred at all.

Ask who holds each licence, whether it transfers, and what it costs to renew. This is not hypothetical: sites do get takedown notices years later for images the client believed they had bought.

Domains, hosting and the accounts

The clause here is simple. Every account is registered in your organization's name, with your billing details where you are paying, and you hold administrative access from day one — not on request, not at handover.

That covers the domain registrar, DNS, hosting, the CDN, analytics, search console, the email or transactional mail provider, and any SaaS the site depends on. The agency can and should have their own access, but as a user on your account rather than the other way round.

The reason to insist is not distrust, it is continuity. A domain registered on an agency's account is an existential dependency on a company you do not control. If they are acquired, go under, or simply stop answering email, recovering a domain you do not formally hold is slow, and occasionally it is not possible at all. The same goes for DNS: it is the switch that turns your organization off.

Where an agency resells hosting, which is a normal and often good arrangement, ask what happens to the site if the reselling relationship ends, and whether you can be migrated to a direct account without rebuilding.

An exit that actually works

Most contracts that address exit at all say something like "the supplier will provide a copy of the site on termination." That is not enough to be useful, because a copy of the files is not the same as a site somebody else can run.

Specify what a handover contains: a full export of code and database, documentation of the build and deployment process, environment variables and configuration, a list of every third-party service and licence with account details, and the credentials themselves. Specify a timeframe, and specify that it is provided at no additional cost.

That last point is the one to hold. A handover priced at the moment you have decided to leave is a hostage arrangement, and it is where a bad ending gets expensive.

For substantial or business-critical builds, consider going further and requiring that the code sits in a repository you own throughout the project, with the agency working in it. Then handover is a question of removing their access rather than a delivery event that can be delayed or disputed.

What happens when they disappear

Agencies close, get acquired, and change direction. Ask what happens to your site if the supplier ceases trading, and make sure the answer does not depend on their goodwill at the time.

If ownership, accounts and repository access are all arranged as above, the answer is straightforward: you already hold everything, and you need a new supplier rather than a rescue. If any of the three is missing, you have a problem whose difficulty scales with how long the relationship lasted.

Support and maintenance, separated from ownership

Keep these apart in the contract. It is entirely reasonable for continued support to be a paid arrangement that ends when you stop paying. It is not reasonable for your ability to use, host or modify the site to end with it.

Where these are conflated — most often by a monthly fee that bundles hosting, maintenance and an implicit licence to your own website — leaving means losing the site. Ask directly what you retain if you cancel, and get the answer in the contract rather than in an email.

Put it in the RFP, not the negotiation

All of this belongs in the document you issue, in a short terms section, phrased as expectations bidders confirm they accept.

Doing it early is worth more than doing it well later. Every bidder is competing and therefore agreeable; after selection you are negotiating with a single party who knows you have chosen them. It also functions as a filter. A supplier whose business model depends on holding your domain, licensing your own site back to you, or charging for handover will either decline to bid or object during the question period — and either way you have learned something you would otherwise have found out years in.

Watch for quiet non-acceptance too. A proposal that simply does not mention your terms section has not agreed to it, and that should be caught in the disqualifying checks before scoring begins.

Where to get the wording

Section 11 of the RFP in our template pack contains these as ready clauses covering ownership, licensing, hosting, exit, change control and warranty. Adapt them to your procurement rules, and have counsel review anything contractually significant — this article is general guidance rather than legal advice.

It pairs with our post on red flags in website proposals, which covers how vague ownership language reads when it turns up in a bid, and with writing evaluation criteria, where acceptance of these terms belongs among the pass-or-fail checks. When your document is ready you can send it to us.