It is easy to assume that paying for a website means owning it. Sometimes that’s true. Often it’s partly true in a way nobody explains until it matters.
The confusion is that “ownership” isn’t a single thing. It’s four separate things that can be held by different people, and you can own some while owning none of the others.
The four pieces
The domain. Your address on the internet. Registered to a person or company, renewed annually.
The content. Your words, your photos, your prices, your service descriptions.
The site itself. The actual files that make the pages work — the design, the code, the structure.
The hosting. The server the site lives on and the account it lives under.
You can own your domain and not be able to move your site. You can own your content but have no practical way to extract it. These are different questions and they deserve separate answers.
The domain trap
The domain is one of the most important control points; losing registrar access can disrupt the website, email, and the ability to manage the business’s address online. It’s usually not malicious — just convenient at the time.
A designer registers the domain for you during setup, using their own account, because it’s faster than walking you through it. Years later you want to move, and the domain is legally theirs. If the relationship is good, they transfer it and it’s a non-event. If the relationship has soured, or they’ve stopped responding, or the business closed, you’re negotiating for your own business address.
The fix takes five minutes. Register the domain yourself, in your own name, with your own account at a registrar. Give your designer access if they need it. Access is easy to grant and easy to revoke. Ownership is not.
If a domain is already registered under someone else’s account, ask to have it transferred to yours. A reasonable answer is “sure, here’s how.” Anything else is worth paying attention to.
One practical note if you’re moving a domain: transfers are subject to standard lock periods. Both Wix and Squarespace document a 60-day lock after a domain is registered, transferred, or has its registrant contact changed. Worth knowing before you plan a move around a specific date. And if the domain came free with a platform subscription, Squarespace’s own documentation notes the free arrangement doesn’t survive the transfer — you start paying registrar rates.
The exit test
Everything else clarifies if you ask one question:
If you stopped working with this person tomorrow, what would you still have?
Push for specifics:
- Would the site keep running, or does it depend on their account staying open?
- Could another developer pick it up, or would it need rebuilding from scratch?
- Could you get your content out in a usable form, or is it locked inside a platform?
- Does anything stop working if you stop paying a monthly fee?
You’re not being adversarial by asking. You’re asking what happens in the ordinary case where a business relationship ends, which can happen for entirely unremarkable reasons. It belongs on the same list as the other questions worth asking before you hire anyone.
Where lock-in usually comes from
Site builders. This is worth being precise about, because the platforms’ own documentation is clearer than most summaries of it.
Wix states plainly that a Wix site cannot be exported or hosted elsewhere — the site “must run on Wix’s servers” because the platform uses its own proprietary technology. Wix affirms that the content you create is yours, and individual Wix products document CSV exports of tabular data such as contacts and products. But there is no export of the site itself, and Wix’s support documentation states that exporting blog posts to other platforms is not currently possible.
Squarespace does offer an export, which produces a single .xml file aimed at WordPress. Its documented limits matter more than its existence: one blog page only, no store or portfolio or index pages, no page-specific headers and footers, and no style settings or custom CSS. Squarespace also notes it isn’t possible to export from one Squarespace site and import into another.
None of that makes these bad products. They’re good products with a specific trade attached, and for many businesses it’s an acceptable one. Just know it’s the deal you’re making. Custom build vs. website builders goes through when that trade is the right one.
What happens if you stop paying differs between platforms in a way that surprises people. On Wix, canceling a premium plan leaves the site online — it reverts to a free wixsite.com address and Wix ads appear. On Squarespace, canceling takes the site offline; visitors see an expired-website message, though your data is retained in the account until you delete it. Ask which of those two behaviors applies to whatever you’re signing up for.
Proprietary agency systems. Some agencies build on their own in-house platform. This is a high-lock-in model, because there’s often no other developer who can take it over. Ask directly whether the site is built on something standard.
“We’ll handle the hosting.” Often convenient. The question is whether the hosting account is in your name or theirs, and whether you could move the site elsewhere if you wanted to.
Bundled monthly plans. If the build was cheap or free because it’s attached to a subscription, find out precisely what happens on cancellation.
The ownership inventory
“The website” is shorthand for a dozen separate things, each held in an account, and the exit test above is really twelve small questions. Run the inventory — for each item, the question is the same: whose account is it in, and could you get into it today without calling anyone?
- The domain registration — the big one, covered above. Your registrar account, your name.
- DNS — sometimes managed at the registrar, sometimes at the host, sometimes at a third service. Whoever controls DNS can point your domain anywhere.
- The hosting account — not just “where the site is,” but whose login it sits behind.
- The source files — the actual site. Do you have a copy, or a right to one in writing?
- The platform or CMS login — with your own owner-level account, not a seat on someone else’s.
- Your written content — retrievable in usable form, not only rendered inside pages.
- Your photography — the original files, not the compressed versions on the site.
- Form submissions — where do inquiries actually arrive, and who else can see them?
- Google Search Console — if it’s set up, you should be an owner, not a guest. It’s how you see what Google knows about your site, and it can end up stranded in a former provider’s account when access wasn’t set up in your name to begin with.
- Business email — if your email runs on the same domain, know where it’s hosted and who administers it. Losing email in a website dispute hurts more than losing the website.
- Backups — do any exist, where, and can you restore without the provider?
- Licenses — fonts, stock images, plugins, themes. Purchased under whose account? A license bought under a provider’s agency account may not transfer to you.
You don’t need to hold every item personally — providers legitimately administer plenty of this. You need to know where each one lives, and the written answer belongs in the project agreement, not in anyone’s memory. A provider who answers this inventory crisply, unprompted, is showing you real account and ownership discipline — a good signal about how they handle access, not proof of everything else they do.
To run this inventory interactively — with the exact questions to ask whoever holds each item — use the website ownership exit test.
The tradeoff on the other side
Portability isn’t free either, and it’s worth being straight about the cost.
A site built as plain static files is highly portable: with the source files and build instructions, another web developer can generally move or maintain it across many compatible hosting environments. But without a content management system attached, you can’t log in and edit the text yourself. Changes go through whoever builds it, or through you editing files directly.
If your content changes only a few times a year — services, pricing, and contact details updated when something changes — that’s usually fine, and a CMS is overhead you’d be paying for and rarely using.
But if you’re publishing regularly, running events, or updating inventory, self-editing matters, and a platform that gives you that is worth its constraints. Neither answer is correct in general. They’re correct for different businesses.
Where TruePoint sits
The domain ends up in your name either way, and which route you take depends on where you start. If you don’t have one, we register it for you and transfer it into your own registrar account at handover — your login, your billing details, your name on the record. If you already have one, it stays exactly where it is and the new site goes on it; that takes one nameserver change at your registrar, which we send you with instructions or walk you through while you stay logged in. We never ask for your registrar password and we never hold your credentials.
The sites we build are static files on a standard, widely-used foundation. No proprietary platform, no in-house system only we can maintain. A developer familiar with standard static-site tooling could take one over — that’s deliberate, not incidental.
Hosting runs on Netlify under your own account, and no subscription to us is required to keep the site running — optional ongoing care exists, but the website never depends on it. One caveat worth stating rather than glossing: Netlify’s free tier now works on a monthly credit allowance, and a site that exhausts its allowance is paused until the next cycle. For a small business site the free tier is normally comfortable, but it isn’t unlimited and it isn’t a promise — Netlify sets those terms and can change them. If traffic outgrows the allowance, or the allowance itself changes, the fix is a paid plan on your own account rather than a call to us.
And the CMS tradeoff applies to us too: without one, you don’t edit page content yourself. If your business needs frequent self-service updates, say so early — that’s a real requirement, and it should shape who builds it rather than turning into a surprise later.
If you’re weighing this against a site builder, custom build vs. website builders goes through when each one makes sense. If you’re earlier than that and mostly want to know the numbers, what a small business website actually costs covers the ranges, and the website packages page sets out what each of our scopes includes.