Do You Actually Own Your Website? Code, Hosting & Lock-In Explained
AI-Extractable Summary
"Most Australian small business owners think they own their website. Many don't — they rent it. Here's exactly what website ownership means, how to check what you actually have, and what to insist on before you pay for your next build."
The phrase "I own my website" comes up constantly. Most of the time, it's only partially true — and the part that's missing tends to matter most when something goes wrong.
This is a practical explainer, not a legal one. It covers what ownership actually means in a web development context, how platform lock-in works, and what you should check today.
What does "owning your website" actually mean?
Think of a website as having four separate layers, each of which can be owned or rented independently:
- The domain name (e.g.,
yourbusiness.com.au) — registered with a registrar like Cloudflare, Crazy Domains, or Namecheap. - The hosting — the server infrastructure that stores the files and serves them to visitors.
- The code — the actual software: HTML, CSS, JavaScript, server-side logic, config files.
- The content — text, images, videos, copy, data.
Most people genuinely own their content. Domain and hosting ownership is variable — sometimes they control it, sometimes it sits in an agency's account. Code ownership is where things fall apart most often, and it's the layer that matters most for long-term flexibility.
Full ownership means: your name on the domain, your billing card on the hosting account, and the full source code sitting in a repository you can access. At that point, no single supplier is a dependency.
Partial or no ownership means: the code runs inside a platform you subscribe to (Wix, Squarespace, a proprietary CMS), or the agency keeps the repository and builds in a way that only makes sense on their infrastructure. You're paying monthly to keep your own site alive.
What is platform lock-in, and why does it matter?
Platform lock-in happens when your website is built in a way that can only run on one specific platform or hosting environment — typically because the platform is both the builder and the landlord.
The most common examples:
Wix. Your site is stored on Wix's servers in Wix's proprietary format. You can export your content to some degree, but you cannot export the site itself. If you want to move to faster hosting, hire a developer to add a custom feature, or change the fundamental architecture, you're starting from scratch.
Squarespace. Similar story. You get clean templates and a good editor, but the code is Squarespace's. Any developer you hire can only work within what Squarespace exposes via its editor — there's no "here's the codebase, do what you want with it."
Proprietary agency CMS. Some agencies build on their own content management system, which runs on their servers and is maintained by them. The code is theirs. You're essentially licensing the software and the hosting from the same party — meaning leaving them means rebuilding.
Page builder plugins on WordPress. WordPress itself is open-source and fully portable. But a site built entirely with a page builder like Divi or Elementor is more tightly coupled to that plugin than it appears. Removing it often requires rebuilding from scratch, and the output code is not clean or portable.
None of these are scams. For a side project or a quick proof-of-concept, Wix is a perfectly sensible choice. The problem is when businesses treat these platforms as a permanent solution without understanding what they can't do later — and then get surprised when the cost of change is "rebuild everything."
How do you check what you actually own right now?
If you have an existing site, run through this checklist:
Domain. Log into your registrar account. Do you have it? Can you change the nameservers without calling anyone? If you have to email your developer to "point the domain somewhere," you don't control it — they do.
Hosting. Can you log into the hosting account directly (cPanel, Cloudflare Pages, AWS console, or similar)? Do you have credentials that weren't given to you by the agency? If the hosting is managed entirely by one provider and you've never been given an account, you're dependent on them.
Code. Does a code repository exist that you have access to? (GitHub, GitLab, Bitbucket.) Can you download it? Has the agency given you a ZIP of the complete source? If you have a WordPress site, you should be able to export the theme and plugins. If you have a custom-built site and there's no repository you can access, ask for one today.
Content. Can you export all your data — posts, pages, customer records, form submissions — in a format a developer could import elsewhere? WordPress has an XML export built in. Most bespoke CMS platforms export via CSV or JSON. If there's no export function, your data is more locked in than you might think.
What should a proper handover look like?
A legitimate web development engagement ends with:
- Code repository transferred to your account — not "we'll keep it hosted for you." Yours, in a repo you own.
- Domain registered in your name — or transferred to your registrar account if the developer registered it initially.
- Hosting credentials — either in an account you own, or documented clearly so migration is straightforward.
- A brief handover document — what was built, what third-party services are in use, what the monthly costs are, and how to make basic updates.
- Any access to third-party services (Stripe, Mailchimp integrations, Google Analytics, etc.) should be under accounts you own and have invited the developer to, not the other way around.
This isn't complicated. It's how any professional engagement should end. If an agency resists providing any of this — "we need to keep the repo for maintenance," "the domain is simpler in our account" — that's a lock-in arrangement by design.
Why does Australian hosting matter?
Code ownership and hosting location are separate questions, but both matter.
A Brisbane business with a server in Virginia (US-East, which is a common default on cheap hosting plans) is adding 200–300ms of round-trip latency to every visitor request from Southeast Queensland. That latency compounds into Google's Core Web Vitals metrics, which feed directly into search rankings. It's a measurable, correctable disadvantage that often goes unnoticed.
Australian hosting — AWS Sydney, or comparable regional providers — keeps your site fast for local visitors, keeps your data under Australian law, and makes support easier (same timezone, same jurisdiction). At Hireadev, every site we build is deployed on Australian infrastructure.
Where Hireadev stands on code and hosting ownership
We're explicit about this in every engagement: at project completion, the full source code transfers to the client. Full stop. You get the repository, you get the credentials, and you can take it anywhere.
Hosting is a separate, optional arrangement at $30/month — managed Australian infrastructure with backups and monitoring included. If you want to host elsewhere, we'll set it up on your infrastructure instead. The code isn't held hostage to the hosting contract.
The same principle applies to domains: we register them in your account (or transfer them to you) before we start, not after.
This matters because a website is a business asset. An asset you can't freely transfer, sell, or modify without permission from the original vendor isn't really an asset — it's a liability dressed up as one.
What should you insist on in a contract?
Before signing with any web developer, confirm these points in writing:
- IP clause explicitly states that all code, designs, and assets transfer to the client on final payment
- The developer will not retain access to your hosting or domain after handover unless explicitly invited
- Hosting is itemised separately and is optional — not a condition of the code running
- The code is built on open-source or widely-supported frameworks, not a proprietary in-house system
For projects with us, see our web design and development service details — ownership terms are standard in every contract, not a negotiation point.
The practical bottom line
If you're not sure what you own, assume you own less than you think and verify. Spend 30 minutes this week checking your domain registrar, your hosting account, and whether a code repository exists that you have access to.
If you're planning a new site or a rebuild and ownership is a priority — which it should be if this site is generating revenue — make it a contractual requirement, not an assumption.
View our pricing for what a fully owned, Australian-hosted, hand-coded website actually costs. Or get in touch if you'd like a straight conversation about what you currently have and whether it's worth rebuilding.