Own Your Website: The Checklist That Keeps Agencies Honest

The Website Hostage Situation

Every so often, a studio owner discovers something uncomfortable: the website that brings in the work does not actually belong to the studio.

The discovery almost always happens at a moment when you can least afford it:

1. A client asks for direct access. The business you are pitching wants to see the site and its hosting for themselves, and finds the whole thing sitting in an unversioned third-party builder account with no history and no handover notes.
2. You need to change three lines. A price goes up, an address moves, a case study has to come down, and the platform quotes a three-week backlog and a change-order invoice more than the work is worth.
3. The vendor changes the terms. The builder you depend on raises its prices, ships an ad network into your pages, or announces an end-of-life date, and the site you have maintained for years belongs to them.

When a studio cannot rebuild, redeploy or check its own website within an hour, that studio is a hostage — and it is paying rent for the privilege.

┌─────────────────────────────────────────────────────────────────────────────┐
│                THE OWNERSHIP QUESTION, ANSWERED IN ONE LINE                 │
├─────────────────────────────────────────────────────────────────────────────┤
│ COULD ANOTHER DEVELOPER TAKE OVER YOUR SITE NEXT MONTH?                     │
│                                                                             │
│ If the answer is no, you do not own your website. You have borrowed it,     │
│ and the terms of the loan are set by somebody else.                         │
│                                                                             │
│ If the answer is yes, everything else on this page is detail.               │
└─────────────────────────────────────────────────────────────────────────────┘

This is not a purity test. It is the difference between a studio that can promise a client a handover, and one that has to go and ask.

1. The Four Things Worth Holding On To

Ownership of a website comes down to four things. Get these right and the rest is detail.

The fourth one is where most studios get it wrong, and it is the one a client will test at the worst possible moment. If your client contract does not say who owns the code, your client will find out at the same moment you do, and they will find it out from the platform rather than from you.

2. The Audit: The Usual Setup Vs. What You Want

How does your current arrangement compare against what you would want if you were handing your own site to somebody else tomorrow?

Every row on the right is something you can offer a client without taking it on trust. A studio that can hand over a repository, a deploy command and a domain account is a studio that does not have to make excuses.

3. The 10-Point Ownership Checklist

Before you sign another annual retainer with a platform, or approve a hosting invoice, run these ten checks. They take an afternoon.

Section A: Custody & Access

1. Domain ownership: Is the domain registrar account held under the studio’s own email address, with 2FA enabled? Try logging in yourself and changing the contact email. If you cannot, it is not yours.
2. DNS and hosting access: Are the name servers and the hosting account in accounts you can reach, rather than in a platform vendor’s account you have been given temporary access to?
3. Hardware-backed security: Are the administrator accounts protected by a physical security key (FIDO2/WebAuthn) rather than a shared SMS code? NIST’s digital identity guidelines require at least one phishing-resistant option at AAL2, and describe WebAuthn and FIDO2 as that option.

Section B: Technical Architecture & Portability

4. Standard web standards: Can the site be built and deployed on any developer’s laptop with open-source tooling, with no proprietary licence required?
5. No live database dependency: Does the public site work without a running SQL database that could crash or leak customer data?
6. No locked-in plugins: Has the site been cleared of closed-source plugins and visual builders that charge a recurring fee for functionality that should have been built in?

Section C: Contractual & Client Protection

7. Absolute IP assignment: Does the client contract state, without qualification, that the custom code and configurations belong to the client?
8. No copyleft contamination: Is there a guarantee that no copyleft open-source licence (such as GPLv3) has been mixed into the work? GPLv3’s Section 5 requires licensing the entire work under the same licence to anyone who receives a copy, which is a serious problem in commercial code.
9. Automated backups: Are build artefacts and repository snapshots archived automatically, in more than one place, so a bad deploy is not a lost week?
10. Three-hour portability: Could a new senior engineer take the repository, run the tests and deploy a fix within three hours of being handed the keys?

Conclusion: Ownership Is What Lets You Be Honest

None of this is about distrusting the vendors you work with. Most agencies are careful, and the good ones hand over everything without being asked twice.

It is about what happens on the worst day. The platform raises its prices, the builder is discontinued, a client needs the site moved to somebody else, or you need to change a price on a page you do not technically own. On that day, the difference between a studio that owns its stack and one that rents it is the difference between a week of work and a month of arguments.

Clients cannot see your stack, but they can see whether you have one. Hold the domain, the code and the accounts, and the promise you make to a client is a promise you can keep.

Is your web infrastructure really yours? Model the scope of a handover with our estimator.