The case for owning your website code (and what that actually means)

Most business owners think they own their website if they own the domain name. That's only part of the picture, and it's a dangerous oversimplification that can cost you thousands in legal fees, rebuild time, and lost traffic if things go wrong.

Website ownership isn't a single thing. It's a collection of assets: your domain name, your hosting account, your design files, your codebase, your content, and your analytics data. Lose control of any one of them, and you've lost meaningful ownership of your site. This article walks through what ownership actually looks like, what can go wrong, and how to protect yourself, especially if you're hiring someone to build your site.

Domain ownership vs. code ownership: they're completely different

Let's start with the most common mistake. You can own your domain name outright, it's sitting on your registrar account, you have the admin access, you pay the bills, and still not own your website code.

When you hire a web designer or agency to build your site, the work they produce (the design, the HTML, CSS, JavaScript, all of it) is their intellectual property unless you explicitly say otherwise in a contract. Many designers treat the code as their own work, like a sculptor keeping rights to a sculpture they created. If the relationship goes south, they go out of business, you have a dispute, or they simply refuse to hand the code over, you're stuck. You own the domain but not the actual website. You'd need to rebuild from scratch, which can cost £2,000, £10,000+ depending on complexity.

This is why owning your website source code matters just as much as owning your domain. The code is the blueprint. Without it, you can't migrate to a new host, hire a different developer, or prove what you're actually paying for.

What "owning your code" actually means

In practical terms, owning your website source code means:

• You have a copy of the codebase on your machine or in a repository you control (typically GitHub or GitLab). You can read it, modify it, and deploy it yourself if needed.
• The code is yours in writing, signed off in a contract. "Work-for-hire" language in your client agreement means the intellectual property passes to you on final payment.
• You're not dependent on the original developer to make changes. You can hire someone else, or do it yourself, without needing permission or facing lock-in fees.
• You understand the technology stack. If your site is built on Next.js with a PostgreSQL database, you (or your new developer) can work with those tools independently. If it's built on a proprietary platform that only one agency knows, you're locked in.

Some platforms make this easier than others. A custom-built site on open-source tools (like Next.js, React, or Django) is infinitely more portable than a site built on a proprietary drag-and-drop builder or a platform like Wix. With bespoke web design, you typically own the code from day one. With a website builder, you don't, you're renting the platform.

That distinction matters most when things change: you need a new feature, your designer disappears, or you want to move hosts.

The real costs of losing code ownership

Here's where the stakes get concrete. If you hire someone to build your site and the agreement doesn't specify that you own the code, and something goes wrong, recovery can be expensive and slow:

• Legal dispute costs: Sending a cease-and-desist or suing for breach of contract can cost £1,500, £5,000 in solicitor fees alone, even before it reaches court.
• Domain transfer and dispute resolution: If the developer registered your domain in their name (not uncommon with inexperienced consultants), you might need to file a UDRP complaint (Uniform Domain-Name Dispute-Resolution Policy) with ICANN. That costs £300, £800 and takes weeks.
• Rebuild costs: If you can't recover the original code and you need your site back online, you're paying for a new build, often at rush rates, which inflates costs by 30 to 50%.
• Lost revenue and SEO: If your site goes offline during a dispute or rebuild, you lose traffic, email subscribers may bounce, and your search rankings take a hit. For a service business losing weeks of inquiry traffic, that's often more painful than the build cost itself.

These scenarios aren't hypothetical. They happen regularly when freelancers go quiet, agencies over-promise and under-deliver, or founder disputes leave a site stranded mid-transition.

No lock-in web design: what to ask for

When you hire someone to build your website, you should expect no lock-in, that means portable code, standard tools, and clear ownership from day one. Here's a checklist:

• Source code access: Ask for the full codebase (all files, Git history, database schemas). Get it in writing that you own it.
• Open-source technology stack: Insist on standard tools you can hire for elsewhere, React, Node.js, WordPress, etc. Avoid proprietary platforms unless you have a very specific reason.
• Hosting control: Your hosting account should be in your name, not the designer's. You should be able to log in, manage DNS, and switch providers if you need to.
• Database and content: If there's a CMS, you should be able to export your content. A CMS built on headless architecture typically gives you more portability than a tightly integrated one.
• Clear handover documentation: The designer should provide a deployment guide, a list of credentials, and notes on how the site works. This becomes crucial if they're unavailable later.
• What happens next: Get clear terms on updates, fixes, and ongoing support. What's included? What costs extra? How long do they stay available?

When you're switching web design agencies, this becomes even more important, you'll be evaluating not just the new designer's work but their willingness to respect code you already own.

Partial ownership: the overlooked trap

Most businesses own some of their website but not all of it. You might own your domain and your content, but not the custom integrations, the email system, or the analytics setup. Each of these components has its own vendor lock-in risk.

Example: You own your domain and your Strapi CMS (an open-source content management system), but your email goes through the designer's SendGrid account. When you switch providers, you lose email forwarding history, and if they disappear, you lose the ability to send emails from that domain at the moment you need it most.

The antidote is an asset-by-asset checklist:

• Domain: you own the registrar account?
• Code and design files: in your repo or handed over in writing?
• Hosting: your account, your payment method, your ability to log in?
• Email: do you control the email forwarding, or is it tied to someone else's SendGrid/Gmail account?
• Analytics: is the Google Analytics property in your account, not the designer's?
• Integrations (Stripe, Mailchimp, etc.): do you have admin access and the API keys?
• Content and images: do you have originals and usage rights?

If any of these are "no", you don't fully own your website, you're dependent on the person or company that does.

Building for ownership from the start

The good news: you can avoid most of this by choosing the right partner and asking the right questions upfront.

Look for a web designer or agency that's transparent about ownership from the start. They should:

• Hand you the source code and credentials on launch (or move you to an "Own It" model where you get the full codebase immediately).
• Use standard, open-source tools that you can hire for elsewhere.
• Keep hosting in your name, not theirs.
• Write contracts in plain English that clearly say "this code is yours".
• Provide onboarding and handover documentation so you're never dependent on them for basic maintenance.

If a designer refuses to do any of these, or makes it sound complicated, that's a red flag. Website ownership shouldn't be a negotiation, it should be the default.

The moment you launch, you should be able to answer "yes" to this question: If this designer disappeared tomorrow, could I keep my website running, make changes myself, or hire someone else to help? That clarity is worth more than any feature set or portfolio.