On this page
A shop owner messaged me last year asking for "a small change" to their website. New phone number, that was all. Their old developer had stopped replying to messages months earlier.
We couldn't do it. The domain was registered under the developer's personal account, the hosting was in their name, and nobody had a copy of the code. Changing one phone number turned into buying a new domain, rebuilding the site from screenshots, and reprinting business cards. The old domain kept pointing at a dead page for months.
I hear some version of this story a few times a year. The developer usually isn't a villain. Someone moved cities, got a full-time job, lost a laptop, or just forgot. The problem is that the business never owned the pieces of its own website.
The three things that make up "your website"#
When people say "my website", they usually mean what they see in the browser. Behind it are three separate things, and each one can belong to a different person.
The domain is the address, yourbusiness.com. It's rented from a registrar a year at a time. Whoever controls the registrar account controls where that address points, and that includes your email if it runs on the same domain.
Hosting is where the files live and get served from. If you don't have access to the hosting account, you can't fix anything, move anything or even see what's there.
The code is the website itself: the pages, styles, images and any admin panel. If you don't have it, the only person who can change the site is the one who does.
Lose control of any one of these and you're dependent on someone else's goodwill and availability.
How businesses end up not owning their site#
It's rarely sneaky. Usually it's convenience.
The developer registers the domain on their own account because it's faster than walking the client through it. Hosting goes on the developer's reseller plan because it's cheaper in bulk. The code sits on the developer's laptop because the client never asked for it and wouldn't know what to do with a zip file anyway.
Everything works fine, for a while. Then the developer becomes unreachable, or the relationship goes sour, or the business wants to switch to someone else. That's when everyone discovers who actually holds the keys.
Some providers also build sites on their own closed platform on purpose. You can use the site as long as you keep paying them, but you can't export it. That's a legitimate business model as long as it's stated clearly. It's a problem when the client only finds out on the way out.
What to ask before you hire anyone#
Ask these before paying a deposit. The answers should be in writing, in the quote or the agreement.
Will the domain be registered in my name, with my email as the account owner?
Which hosting provider will you use, and will the account be under my email?
Will I receive the full source code when the project is paid?
If you're unavailable in a year, can another developer take over without you?
Are there any licences (themes, plugins, fonts) I'll need to renew myself?
A good developer won't be offended by any of these. If someone gets defensive about question one, that tells you a lot.
The handover checklist#
When the site is finished and paid for, here's what you should walk away with. Keep it all in a password manager or at least in one safe document, not scattered across chat history.
Accounts#
Registrar login for the domain, with your email as the owner, two-factor authentication on, and auto-renew switched on.
Hosting account login, again under your email. For static sites this is often Cloudflare Pages, Vercel or Netlify, and the free plan is usually enough.
DNS access, if DNS is managed somewhere other than the registrar (Cloudflare is common).
Business email login if the email runs on your domain.
Admin panel login if the site has a CMS, as an owner or administrator account rather than an editor account.
Tracking and search tools#
Google Analytics, with you as an administrator on the property, not just a viewer.
Google Search Console, with your account added as an owner.
Meta Pixel and any ad accounts linked to your own Business Manager.
Files#
The complete source code, either as a repository you own (a GitHub account in your name is ideal) or at the very least as a zip archive.
The original images, logo files and any fonts that were bought for the project.
A short document explaining how the site is built and deployed, so another developer can pick it up quickly.
Dates and costs#
When the domain expires and what renewal costs.
Any other yearly bills: hosting, licences, email.
"But I'm not technical"#
You don't have to be. You don't need to understand the code to own it, the same way you don't need to be a mechanic to keep the papers for your car.
What matters is that the accounts are under your email and you can log in. If something goes wrong, any competent developer can take over from there.
How I handle it#
On every project I do, the domain is registered in the client's name from day one. Static sites go on a hosting account the client owns. When the final payment comes in, I hand over the domain login, the hosting account, the source code and admin access, along with a short note on how everything fits together. I don't keep anything back, and I don't hold sites hostage over unpaid invoices either. That's what the 50/50 payment split is for.
It's written into every quote on my services page, because I think it should be the default everywhere.
If you're not sure who owns your current website, start with the domain. Look it up on a WHOIS service, or ask your developer directly which account it's in. If it turns out not to be yours, it's much easier to fix that now, while everyone is still on speaking terms.
Want help untangling an existing site, or building a new one you'll fully own? Message me on WhatsApp.
Need something like this built?
I design and build fast websites, internal systems, and automation for companies and institutions. Fixed pricing and direct communication.