There is no universal answer to "who owns the website?" because a website contains several different things: the domain, code, design, written content, photographs, fonts, software and third-party services can all have different ownership or licence terms. The project agreement should make the position clear before work starts.
This is one of those subjects that sounds simpler than it is.
A client pays a web designer.
Naturally, they think:
I bought the website. So I own the website.
Commercially, that expectation is understandable.
Legally and technically, the detail can be more complicated.
The useful solution is not to turn every web project into a law lecture.
It is to make the important rights and access arrangements explicit.
Start with the domain
The domain is separate from the website itself.
The business should normally control its registration and registrar access.
That means if the development relationship ends, the business still controls the public web address.
I cover that separately in who should own your business domain.
Domain control is one of the easiest ownership questions to solve properly from the beginning.
Then there is the website code
The code may have been written specifically for the project.
It may also incorporate libraries, frameworks or other software released under existing licences.
A contract can specify what rights in the bespoke work transfer to the client and what remains licensed.
Do not assume that paying an invoice automatically answers every copyright question.
In Ireland, copyright can be assigned, but the Copyright and Related Rights Act says an assignment must be in writing and signed by or on behalf of the person assigning it.
That alone is a good reason to put ownership terms into the agreement rather than rely on assumptions.
This is not legal advice
Copyright depends on the work, contract, creator, employment relationship, licences and applicable law.
If there is already a dispute over valuable intellectual property, speak to a solicitor.
My point as a developer is much more practical:
the client and developer should not reach the end of the project with completely different ideas about what was sold.
Clear written terms prevent that.
What about the design?
The visual design may contain bespoke creative work.
It can also rely on licensed assets.
Fonts.
Icons.
Illustrations.
Photographs.
Libraries.
Those third-party elements may carry their own terms that neither the developer nor client is free to rewrite.
So "the client owns everything" can be too broad.
A better agreement explains the rights the client needs to operate, use and move the website while respecting licences that already exist.
Website copy can have separate ownership
Who wrote it?
The client?
The developer?
A copywriter?
Was it adapted from an old site?
Was it licensed?
Again, the contract can clarify rights to newly commissioned material.
From a practical perspective, a small business should be able to take the content written for its own website and continue using it according to the agreed terms.
That expectation should be explicit.
Photographs often cause confusion
If the client supplied the photographs, they should already know whether they have the right to use them.
If a photographer created new images, the photography agreement matters.
Paying for a shoot does not automatically mean every possible copyright right transfers.
The business may instead receive a broad licence to use the images.
Stock photography also remains subject to the stock provider's licence.
That is why asset licences should not be casually ignored during a handover.
Fonts can be licensed too
A font may be free for commercial web use.
Or it may require a paid webfont licence.
The client does not suddenly own the font because it appears on the site.
They need the right to use it.
For a small business, this is normally straightforward.
But it is another example of why "I own every file on this website" is not a technically accurate blanket statement.
Software-as-a-service is not something you own
A booking platform.
Email marketing tool.
Payment provider.
Analytics service.
Hosted CMS.
These are usually services used under subscriptions or terms.
The client may own the account and the data they are entitled to under those terms.
They do not own the software company.
That distinction matters when somebody asks whether a website can be moved.
The website may move.
The third-party services may remain separate.
What should a client receive after the project?
For a straightforward custom small-business website, I would want the client to understand and have access to the important operational pieces.
The domain account or clear domain control.
The relevant hosting/deployment account.
The finished site.
The agreed source files or repository access where applicable.
Credentials for client-owned third-party systems.
A clear explanation of any paid licences or subscriptions.
The point is operational independence.
The business should not need to reconstruct its own setup from memory two years later.
Gavin's take
Website ownership is rarely a simple yes-or-no question. A hosted platform can be a perfectly sensible choice even though the client does not receive every piece of underlying software. What matters to me is that the limitation is understood before the sale: what the business controls, what it is licensing, what recurring costs exist and what happens if it wants another provider to take over. A clear licence is far better than supposed "ownership" nobody can actually use.
What about proprietary agency platforms?
Some providers build websites on systems the client cannot take elsewhere.
That can be a legitimate commercial model.
Hosted website builders operate in a similar way.
You are paying for use of the platform rather than receiving a completely portable software package.
The problem is not that these models exist.
The problem is discovering the limitation only when you try to leave.
Ask before signing:
If I stop paying you, what exactly can I take with me?
That answer matters.
A licence is not automatically worse than ownership
This is worth saying.
Businesses license software all the time.
Microsoft 365.
Adobe.
Shopify.
Fonts.
Stock images.
A licence can provide everything the business needs.
The real question is whether the rights are sufficient and the limitations are understood.
"Ownership" can become a vague marketing word.
Practical control often matters more.
Can the business keep operating?
Can it move supplier?
Can it use its content?
Can it access its data?
Can it retain the domain?
Those are the questions I care about.
Gavin’s perspective
What Built by Gavin wants the client to control
My preference is straightforward.
The business should not be unnecessarily locked to me.
I want important accounts structured sensibly.
I want domain control clear.
I want the client to understand recurring third-party costs.
And I want the agreement to be clear about the work being delivered.
I do not think dependency should be used as a retention strategy.
If a client keeps working with me, I want it to be because the service is useful.
Not because leaving would break the business.
Why ownership becomes important when the developer disappears
This is the practical stress test.
Imagine I vanish tomorrow.
Can another competent developer identify the domain?
Access the website files?
Understand where it is hosted?
Keep business email intact?
Continue operating important integrations?
If yes, the setup is healthy.
If the answer to everything is:
Only the old developer knows,
the client has unnecessary risk.
Read what happens if your web designer disappears for that scenario.
What I'd do
Before treating a project as properly handed over, I would want the important pieces written down: domain account, hosting or deployment platform, source files where applicable, paid licences, analytics, forms and any third-party services. My practical test is simple: if the original developer vanished tomorrow, could another competent person understand what exists and take over without rebuilding everything from scratch?
Questions to settle before a website project
This is one place where a short checklist genuinely helps.
Before signing, understand:
- who controls the domain;
- what rights transfer in bespoke code/design/copy;
- which third-party assets are licensed rather than owned;
- who controls hosting and service accounts;
- what happens if the relationship ends;
- whether there are export or migration limitations.
You do not need a 40-page contract for a five-page website.
You do need the important expectations written down.
The bottom line
Website ownership is a bundle of rights and accounts, not one switch marked "owner".
The domain, bespoke work, photography, fonts, software and third-party services can all be different.
The safest approach is simple:
make the important terms clear in writing;
give the client sensible operational control;
and avoid hidden dependencies.
Want a website setup you can actually understand?
See my website options or ask me how ownership would work before you buy anything.
I would much rather answer that question before a project than after somebody wants to move it.
---