Who should own your domain and code?
The short answer
Your business should be the registrant of its own .co.ke domain and should hold the hosting account and code repository. A large share of Kenyan SMEs discover during a dispute that their developer owns all three, which effectively holds the website hostage.
Your website is three things, and you should own all of them.
Most business owners think of the website as one item they paid for. Legally and practically it is three separate assets, each held in a different account, each transferable on its own. Problems start when a business owns none of them and only finds out during a disagreement.
The domain
The address- What it is
- Your .co.ke or .com name, held at a registrar under a registrant record.
- Who should hold it
- Your business, as the named registrant, with an email address your business controls.
- If you do not
- Whoever is listed can move it, let it lapse, or point it elsewhere.
The hosting
The land- What it is
- The account where the files and database live.
- Who should hold it
- Your business, paying the provider directly or holding the login.
- If you do not
- A missed renewal you never saw takes the site offline.
The code and content
The building- What it is
- The theme, templates and custom code, plus the database of your pages.
- Who should hold it
- Your business, in a repository and a backup you can download.
- If you do not
- You cannot move developer without rebuilding.
Nobody sets out to take your website
In almost every case we have seen, this is not malice. It is convenience that nobody unwound.
A developer registers the domain on their own account because it is faster than waiting for the client to create one. They put the site on their reseller hosting because they already pay for it and the marginal cost is nothing. The code sits on their laptop because there was no budget line for a repository. Every one of those decisions saved the client time on the day it was made.
Then something ordinary happens. The business wants to move to a faster host. A new marketing person wants Search Console access. The developer takes a full-time job and stops answering. A fee is disputed. At that moment the three assets stop being admin details and become leverage, and the business discovers that the only thing it actually owns is the logo.
The fix is boring and takes about an hour, which is why it is worth doing now rather than during an argument.
How to check what you own, right now
You do not need your developer’s help for any of this.
Look up the domain record
Run a WHOIS lookup on your domain. For .co.ke names the registry is KeNIC; for .com it is any public WHOIS tool. Read the registrant organisation and the registrant email.
If that email is not one your business controls, you do not control the domain.
Find out who you pay
Check which company bills you for the domain and which bills you for hosting. If the answer to both is "my developer, in one lump", there is probably no account in your name.
A reseller invoice is not an account.
Try to log in yourself
Ask for the registrar login, the hosting control panel login and the website admin login. Sign in once and change nothing.
If a login cannot be produced, that is the finding.
Ask where the code lives
There should be a repository, GitHub, GitLab or similar, with your business as owner or at minimum as an admin member.
"It is on my machine" means the code is not backed up either.
Check the analytics and Search Console properties
Both should be owned by a business email with your developer added as a user, not the other way round.
Years of search data are lost when the owning account goes away.
What a clean setup looks like
- A shared business mailbox, something like
admin@yourcompany.co.ke, owns every account - The domain registrant is your registered business name, not a person and not an agency
- The hosting is billed to your business card or paid directly, with renewal reminders reaching you
- Your developer is added as a user or collaborator, with access that can be removed
- The code sits in a repository your business owns, with the developer as a member
- You can download a full backup of files and database without asking anyone
How to move the accounts across without a fight
Approach this as housekeeping, not as an accusation, because in most cases that is genuinely what it is.
Create the business accounts first
A shared mailbox, a registrar account, a hosting account and a repository, all under the business. Do this before you ask for anything, so there is somewhere for the assets to go.
Ask in writing, with a reason that is not a complaint
"We are tidying up our business accounts for continuity. Please transfer the domain to our registrar account and add us as owner on the hosting and repository." Most developers do it the same day.
Take a full backup before anything moves
Files and database, downloaded to somewhere you control. Transfers are routine but a backup turns a bad day into an inconvenience.
Move the domain, then the hosting, then the code
In that order. The domain is the asset with the hardest recovery path, so secure it first. Hosting can be migrated with almost no downtime if the domain is already yours.
Re-point the renewals
Check that renewal notices now arrive at your mailbox and that the cards on file are yours. This is the step people skip, and it is the one that takes sites offline a year later.
Write it into the next contract
One clause: all accounts registered to the client, all code delivered in a client-owned repository, full backup at handover.
When the answer is no
If a developer refuses to transfer a domain registered in your business name, the registrar and, for .co.ke names, KeNIC have dispute processes, and that is the route to take. If the domain was registered in their name and there is no contract saying otherwise, the position is genuinely less clear, and this is the point to speak to a lawyer rather than to the internet. We are not qualified to advise you on that, and any agency that tells you the outcome with confidence is guessing.
The practical fallback is rarely as bad as it feels. Content can be re-published, a site can be rebuilt, and a similar domain can be registered properly. What you cannot easily recover is an established domain with years of links behind it, which is exactly why the ten-minute check above is worth doing while everyone is still friendly.
Put ownership in the contract
Name the registrant, the hosting account holder and the repository owner before work starts.
Keep the mailbox, not the person
Accounts tied to a staff member's personal email fail the day that person leaves.
Take a backup every quarter
Four downloads a year is enough to make any dispute survivable.
What owners ask us about this
My developer says the domain has to be in their name for technical reasons. Is that true?
No. A registrar account can have multiple users, and a developer can manage DNS without being the registrant. There is no technical requirement for the registrant to be anyone other than your business.
Does owning the code mean I can change it myself?
It means you can hand it to anyone who can. Owning the repository is about being able to change developer, not about doing the work yourself.
We are mid-project. Should I raise this now or wait?
Now, and framed as a setup question rather than a trust question. It is far easier to point a new build at accounts you already own than to transfer everything after launch.
Is a website builder subscription safer?
It solves the developer problem and creates a platform one. You own the account but usually cannot export a working site, so you are still unable to move without rebuilding.
