“I paid for the website, so do I own it?”
It’s a fair question, and the honest answer is that it has several answers — because a website isn’t one thing.
It’s a domain name registered with a registrar. A hosting account with a provider. Code written by somebody. Words and photographs, some yours and some newly created. Fonts, plugins and stock images used under licence. Accounts with analytics, forms and email services, each with its own login and its own bill.
Those parts are controlled, licensed and transferred in different ways. Paying an invoice does not, by itself, answer every question about accounts or rights. The agreement needs to say what happens.
None of this is legal advice, and we’re not lawyers. What follows is a practical guide to the questions worth asking and the things worth getting in writing, whoever builds your site.
Your domain name
Domain names are registered for a defined term, not bought outright. They need renewing to remain registered. The period and transfer rules depend on the domain extension and registrar; for example, Nominet’s .UK policies cover registration, renewal and transfers for .UK domains.
Two things matter here.
Whose name is on the registration. For a business website, the registrant details should normally identify the correct business or legal entity, not the supplier. If an agency registers a domain in its own name, transferring control later may take extra work.
Who can actually get into the account. Registrant details and account access are separate. Your business can be named as registrant while the login sits with someone else.
Agencies managing domains on a client’s behalf isn’t unusual or improper — it’s often genuinely easier. It just needs stating plainly, along with what happens if you part ways.
Questions worth asking before launch:
- Which registrar holds the domain, and whose name is the registrant?
- Does my business have administrator access and a recovery method it controls?
- When does it renew, who pays, and will I be told before it happens?
- If I move to another supplier, what’s the process for transferring it?
Hosting, email and other accounts
The same distinction applies: who holds the account, who pays, and who can get in.
It’s worth separating two kinds of cost. A one-off website build is a project with a price. Ongoing third-party costs — which may include hosting, domain renewal, email, a content management system, form handling or maps usage — depend on the services the site uses. You might pay a provider directly or reimburse your supplier; the proposal should say which. Some static-site arrangements have no hosting subscription, but that does not make the domain or business email free.
Sometimes an agency bundles these into a monthly fee. That can be convenient, provided you know what’s inside it and what happens to those accounts if the arrangement ends.
What to establish:
- Which services the site depends on, and the current recurring cost of each
- Whether accounts are in your business’s name or your supplier’s
- Who pays each bill, and whether that’s billed on to you
- What happens to each account if you change supplier
Email deserves a specific mention, because it’s the thing people most regret leaving with a former supplier. If your business email runs through an account someone else controls, that’s worth resolving early, and separately from the website.
Website code and design files
This is where assumptions cause the most trouble, because paying for work and acquiring every right to it are not automatically the same thing.
What you receive depends on what the agreement says. A proposal that names the deliverables removes the ambiguity. A proposal that says only “website design and build” leaves it to be argued about later.
Things worth seeing named in writing:
The deliverables. Which files you receive at the end — the built site, the source code, design files, or some combination.
Source-file handover. Whether editable design files and the code repository come to you, and in what form.
Reusable components. An agency may use its own templates or components across projects. Some may be licensed for use in your site rather than transferred outright. Ask which parts, if any, fall into this category and whether another developer may maintain or modify your site.
When transfer happens. The contract should give a clear handover point. FinTaxTech’s current process places final payment before launch, source-file transfer or unrestricted delivery.
Third-party code. Open-source libraries, plugins and frameworks come with their own licences that continue to apply regardless of what your contract says.
The useful question isn’t “do I own it?” but “what exactly do I receive, and what am I permitted to do with it?” — including whether you can take it to another developer and modify it.
Words, photographs, fonts and other assets
Three different categories, which behave differently.
Material you supplied. Your existing copy, logo, photographs and documents do not become your supplier’s property simply because you provide them. But check that you hold the rights or permissions needed to use each item on the new site, especially if a third party created it.
Work newly created for you. New copy, custom illustration, commissioned photography, a new logo. Whether rights transfer to you, and when, depends on the agreement and applicable law. In the UK, Intellectual Property Office guidance on commissioned work explains why paying the creator does not automatically transfer copyright. If a new logo is part of the project, our article on logo versus brand identity covers what to ask for. Clients elsewhere should check the rules that apply to their contract.
Third-party licensed assets. Stock photography, icon sets, commercial fonts, premium plugins. These are used under their own terms and should not be treated as automatically transferred with the website.
Licences matter more than people expect. Some cover one website only. Some limit page views or the number of sites. Font licences commonly separate desktop use from web embedding, and price them differently. A licence bought in the agency’s name may not transfer to you.
Ask for a list of every licensed asset used, what the licence permits, whose name it’s in, and whether it needs renewing.
Analytics, forms and connected services
Small accounts, easily forgotten, awkward to recreate.
Depending on the site: Google Analytics, Google Search Console, form handling or email delivery, booking or payment integrations, a CMS subscription, and error monitoring. A Google Business Profile may also be relevant, but it is a separate business account rather than a website component.
Two reasons to retain administrative control. First, continuity: rebuilding a service from scratch may not preserve its settings or reporting history. Some services support a proper transfer — for example, Google Analytics can move a property with its reporting data if the required permissions are in place. Search Console uses site-ownership verification, so that access should be checked before a supplier leaves. Second, some services process enquiries or customer information, making clear access and responsibility especially important.
If you change supplier, you’ll want each account to survive the change rather than being rebuilt from scratch.
A practical handover checklist
Ask for these when the site goes live:
- Domain registrar, account access, registrant details and renewal date
- Hosting account details and access
- Source files and repository access, where the agreement provides for them
- Final approved assets — logo files, images, written content
- A list of licensed assets, with what each licence covers and whose name it’s in
- Named administrator access to analytics, Search Console, forms and connected services — without sharing passwords
- Every renewal date and recurring cost, in one place
- Basic instructions for updating content, if you’ll be doing that yourself
- A backup or export plan — how the site and its content can be retrieved
- A named contact for questions after handover
That last export point is worth thinking about before you choose how the site is built, not after. How easily your content can leave depends partly on the platform, which we cover in our article on static sites, CMS platforms and headless options.
What to agree before work starts
Five questions to put to any website developer, before signing:
- What exactly do I receive at the end, file by file?
- What rights do I have over it, and are any parts licensed to me rather than transferred?
- Which accounts will be in my business’s name, and which in yours?
- What does it cost to run per year, and who pays each provider?
- What happens if I move to another supplier — what comes with me, and how?
Ask these of everyone you’re considering. The answers will differ, and the differences are legitimate. What matters is that the answers exist.
One more thing to keep separate: future changes, maintenance and support should be defined on their own terms, with their own scope and price. Bundling “we’ll look after it” into a build quote without detail is how expectations diverge. Our launch checklist covers what to have ready before you get to this stage.
How we handle it
For our own projects, ownership, deliverables, third-party costs and price are set out in the written proposal for that project, so you can see what you’re receiving before you commit rather than afterwards.
Business accounts — domain, hosting and connected services — stay yours. Final handover of the agreed deliverables follows final approval and payment.
We won’t claim every project carries identical terms, because scope genuinely differs between a five-page site and something larger. What’s consistent is that it’s written down in the proposal before work starts, and you can ask about anything in it before you sign.
Tell us what you need
If you’re planning a new website or a complete rebuild, our questionnaire covers what you’re trying to achieve, who it’s for and what you already have. We’ll review the project and, if it’s a fit, set out the deliverables, ownership and third-party costs in a written proposal.