Nobody asks who owns the website on the day the contract is signed - they ask two years later, at the first serious change. The company wants to move to a different developer or bolt a store onto the site, and it turns out nobody can say whose code it is, whose account the theme was bought on, or where the repository lives. So when someone asks who owns the website, they are usually not drafting a contract. They already have a running site, a paid invoice, and a need to establish how much of it actually belongs to their company.
I look at this from the developer’s side, since building company sites and stores is what I do, and a few times a year I take over a site from somebody else. That takeover is usually the moment the whole thing surfaces. One thing up front: I am not a lawyer and this is not legal advice. I am writing about what you can check with your own hands and what the missing clauses cost in practice. Leave the reading of your actual contract to a lawyer, particularly if it is heading towards a dispute.
Who owns the website after the invoice is paid
Start with the part that surprises most people: paying the invoice does not, by itself, transfer copyright. The invoice documents payment for a service. Economic rights to a work - and the design, a custom theme and any features written to order are works - pass to you when the contract says so explicitly and names what is being transferred. An assignment generally has to be in writing to be effective, which it certainly does under the Polish law I work under, so an arrangement made over email or in a meeting is not the same thing as a clause in a document.
In practice two things drift apart that most clients treat as one:
- Actual control of the site - you hold the files, the database, the admin panel and the hosting. You can log in, change things, copy them.
- Rights to what was made to order - you can lawfully dispose of the project, rebuild it, hand it to another firm for development, reuse the same artwork on a second site.
You can have the first without the second, and that is the most common case I see: the site sits on your hosting, you hold every password, and the contract says nothing about rights. Day to day it does not get in the way - the problem shows up at a rebuild, in a dispute with the developer, or when the company is being sold.
The reverse arrangement is worse: the contract assigns the rights, but the developer never handed over a complete copy of the site and keeps the credentials. A good clause therefore ties the two together and ties both to payment in full - with the final transfer you hold the files and the right to them.
How to check what is actually yours - six questions
This audit does not need to be outsourced. Six questions, and the answers are in your control panels and your inbox.
- Who is the domain registered to? Not who administers it, but who is named as the registrant in the registrar’s panel. No account of your own at the registrar usually means the domain is not yours - and it is the single most important item on this list.
- Whose account is the hosting on, and which email address is attached to it? An account on the developer’s address means that on the day you part ways you are left without the server the site runs on.
- Where does the code repository live and who owns it? A repository inside the developer’s personal account or their GitHub organisation is not your repository, even if you have read access to it.
- Do you have access to the files and the database? Access to the WordPress dashboard alone is not enough to make your own copy - you need an FTP or SFTP account and a database export.
- Whose account are the paid licences on, and who renews them? This covers the theme, premium plugins, sometimes fonts and the on-site search.
- Which of these arrangements is in the contract, and which only in emails? Email proves what the parties agreed, but for copyright it does not replace the written form.
There is also one test that settles everything at once and needs no reading of clauses. Could any other developer stand up a working copy of your site on their own machine without asking the previous one for anything? If yes, you hold it in practice. If something along the way requires a favour, the site is yours on paper only. I run this test at the start of every takeover, and it usually shows the real state of affairs faster than the contract does.
What has to be in the contract
If you have a contract in front of you, look for three statements: the rights to whatever was made to order pass to you, with the moment of transfer named, with what they cover spelled out, and with an obligation to hand over a complete, runnable copy of the site together with the credentials. Without the third, the first two are not enough.
The full list of points that protect a client during a build - scope as an appendix, deadlines, milestones, acceptance, warranty - I set out separately in the piece on what a website build contract has to contain. There are seven points and a walk-through of each; this article is about the situation where the contract is already signed, or where there is none.
A note for anyone working from a template off the internet: the sentence “the client acquires full rights to the website” reads reassuringly and is too vague to do any work. What counts is naming exactly which rights you acquire and for which forms of use - and that is a paragraph for a lawyer.
Themes, plugins, photos - what will never be yours
Part of the site will not pass to you, because it was never the developer’s property in the first place. That is simply how today’s web is built - you only need to know what follows from it when the site changes hands.
WordPress, themes and plugins under the GPL. WordPress itself and most plugins from the directory run under an open licence. Nobody assigns you rights to them because nobody holds them exclusively. What you do get is the right to use them, modify them and move them along with the site wherever you like. What that costs in money I covered in the piece on whether WordPress is really free.
Premium licences, tied to an account and often to a domain. A paid theme or plugin is a licence for a set number of installs, renewed annually, recorded on the account of whoever bought it. If the developer bought it, the day you part ways you stop receiving updates and support, and the plugin starts reporting that the key is inactive. The site keeps running but stops being safe, because security fixes come down through that same key. Which is why licences belong on your account, even when the developer issues the invoice.
Stock photos with a named licensee. This is where the quiet mess accumulates. A stock licence is granted to a specific entity and is usually not transferable - the developer cannot assign it to you even if they wanted to. A site built on photos bought by an agency may therefore need those photos repurchased or replaced once you part ways. The same goes for commercial fonts, whose web licences are often counted per domain or per traffic, and for paid icon sets. And if the copy was written by a subcontracted copywriter, those rights need their own chain too - from the writer to the developer and on to you.
Hence the rule at handover: ask not only for the code, but for a list of everything that sits under a licence, with whose account it is on.
No contract, or parting ways with your developer
Having no contract does not mean you are left with nothing - it means the situation is worth tidying up before a conflict appears. In a calm conversation developers usually have no reason to refuse.
The order I would keep:
- Ask in writing for the full set - a complete copy of the files and database, a list of accounts and licences with whose name they are in, and confirmation that you may dispose of whatever was made to order.
- Move the domain and hosting into your own name. Domain and hosting on your account settle most of these conversations.
- Make your own copy before you start the hard conversations. A copy made today is sometimes the only thing left when a working relationship ends abruptly.
- Straighten out the paperwork afterwards. An annex or a separate assignment signed after the fact is perfectly normal and cheaper than a dispute.
One thing that is easy to forget when changing developers: the new one will not warrant code they did not write. If something breaks after a takeover, the fix is ordinary paid work - I separated those two in the piece on the warranty on a website build.
How I handle it
I set this up so the question in the title never gets a chance to come up. The repository is created in the client’s account on day one, not at handover - I work inside their repository, so the code sits where it is meant to stay from the start. Domain and hosting are registered to the client’s company, with access for me, never the other way round. Paid licences are bought on the client’s account, so updates keep arriving after the engagement ends. Rights to whatever I wrote to order pass with the final payment, in writing, with the scope named.
I do this because it is cheaper for both sides - a client who knows they can walk away does not have to go and check. When I build a company website from scratch or rebuild an existing one, a copy any developer can run, the list of credentials and the list of licences are part of the handover rather than an extra on request.
Summary
A paid invoice gives you a site to use, but copyright passes only when the contract says so explicitly and in writing. The rest is settled by practice: whose name the domain is in, where the repository lives, whose account holds the licences, and whether another developer could stand up a copy without asking your previous one. Part of the site - WordPress, GPL plugins, stock photos, fonts - will never be yours, and that is fine; you just need to know which items on that list stop updating the day you part ways.
If you have a site and do not know how much of it belongs to your company, send me the address and the contract if there is one. I will walk this list and tell you what is missing for the site to move without obstacles.
Frequently asked questions
I have no contract with my developer - is the site mine? You have it in use and nobody is taking that away, but there is no assignment of economic rights without a written agreement. The problem shows up at a rebuild or when the company is sold, so the paperwork is worth straightening out by annex while the relationship is still good. How it stands in your case is for a lawyer to judge.
My developer will not hand over the repository and credentials - what can I do? Start by asking in writing, with a list of specific items and a deadline - the written form alone often settles it, because it organises the conversation. In parallel, check what you have without them: with the domain and hosting on your account you can make a full copy of the files and database yourself. If those sit on the developer’s account, they are the first thing to recover. If they refuse, the next steps depend on what you signed, and that is the moment for a lawyer.
Can I move a site built on a paid theme to another company? The site itself, yes - the files and database travel with you. The theme licence is a different matter: if the developer bought it on their own account, after you part ways you are left without updates and support for that theme, although the site keeps running. The cheapest fix is buying the same licence on your own account, and on new projects buying licences in your own name from the start.
Do the photos used on the site pass to me along with it? Usually not, if they come from a stock library and the developer bought the licence - those are granted to a specific entity and most often cannot be transferred. That is why it is worth receiving a list of the photos used, with their source, at handover. Photos shot to order for you are a different matter, and there the assignment belongs in the contract.
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.