You paid for the website. You own it, right? Not always. One of the more unpleasant surprises in software is a founder discovering, often when they want to switch developers, that they don't actually control the thing they paid to build. It's avoidable with a few questions up front. Here's what ownership really means and what to check.
Why this catches people out
"Building a website" is really assembling several things: the code, the domain name, the hosting, the content, and the various accounts that tie them together. It's entirely possible to pay for the work yet have one or more of those pieces sitting in someone else's name. Nothing dramatic has to go wrong for this to hurt; you just go to make a change or move on, and find you can't.
The pieces you should own or control
- The domain name. This should be registered in your name, in an account you control. It's your address on the internet; never let it live solely in a developer's account.
- The code. The actual source code of your site or app, with the rights to use, change, and move it.
- Hosting and infrastructure accounts. The accounts where your site runs and your data lives.
- Content and assets. Your copy, images, and logo files.
- Third-party accounts. Analytics, email, payment processors, set up under your ownership, with the developer given access, not the other way around.
"Ownership" vs "a licence"
Here's the subtlety. Some arrangements give you a licence to use the software rather than ownership of it, common with proprietary platforms or template systems. That can be fine, but it's a different deal, and you should know which one you're getting. A useful question:
"When this is done, do I own the code outright, or am I licensing a platform you keep? And either way, can I take my site and data elsewhere if I ever need to?"
The answer isn't automatically good or bad, but it should be clear, in writing, before work starts. The same goes for any third-party plugins or paid components used in the build: know what's yours and what's rented.
What to check before you hire
Settle these in writing at the start, it's a normal, reasonable thing to ask, and a good developer won't blink:
- Who owns the source code on completion? (You should.)
- Is the domain registered in my name and account?
- Are hosting and key accounts in my name, with you given access?
- What happens at handover, what exactly do I receive?
- If we part ways, can I take everything and continue elsewhere without obstruction?
This pairs naturally with the prep work in what to prepare before hiring a developer and with choosing the right kind of partner in freelancer, agency, or studio.
A note on lock-in
Some lock-in is technical, not contractual, a build so tangled or undocumented that, even though you "own" it, no one else can reasonably pick it up. That's why maintainability and a clean handover matter as much as the legal answer. Owning code you can't hand to anyone else is ownership in name only.
How we handle it at LyfWis
Our default is simple: you own your code, your domain stays in your name, and accounts are set up under you with us given access. We build for maintainability and hand over cleanly, because a product you can't take elsewhere isn't really yours, and we'd rather earn the next project than trap you in this one. See how we work, or ask us anything about how ownership and handover would work for your project.
Frequently asked
Is it normal to ask a developer about code ownership?
Completely. It's a standard, professional question, and a straightforward answer is a good sign. Hesitation or vagueness is worth paying attention to.
Should the domain ever be in the developer's account?
No. They can manage it with access you grant, but the domain should be registered to you. It's one of the few things that's genuinely painful to recover if it ends up elsewhere.
What if I'm on a platform like Shopify or a hosted system?
Then you're licensing the platform rather than owning custom code, which is fine, just make sure the account is yours and that you can export your data and content if you ever move. See our platform comparison for the trade-offs.
