Our take: the best website is the one you can leave with
Why we measure a website by how easily its owner could take it to another partner, and what that standard forces us to do differently.
The short answer
We judge a website by a simple test: could a competent stranger take it over in a week without talking to us? If the answer is yes, the site is an asset the business owns. If the answer is no, the site is a liability dressed as an asset, whatever it looks like, because the business depends on one supplier for its own front door. Holding ourselves to that standard forces decisions we would defend on their own merits: standard, widely known technologies rather than clever proprietary ones; a named holder for every account and a written route to move any of them; content structured and exportable rather than locked in layouts; setup written in files rather than clicked into dashboards; documentation a stranger could follow; a pipeline anyone can run; and nothing that lives only on our infrastructure or in our heads. It is good for the client, obviously. It is also good for us, because clients who could leave and do not are staying by choice, and a site handed over cleanly is a reference. If a partner cannot describe how you would leave, you have learned what kind of partner they are.
What the standard requires
| Area | What being able to leave requires | What dependence looks like |
|---|---|---|
| Code | In the client’s repository, on standard frameworks | In the supplier’s account, or on a framework only they use |
| Accounts | Domain, hosting, email, analytics, services in the client’s name | Some or all in the supplier’s name |
| Content | Structured, exportable, independent of presentation | Only exists as pages in a proprietary system |
| Setup | Redirects, headers, environments, DNS written in files | Clicked into dashboards; remembered by a person |
| Secrets | In platform secret storage the client controls | Held by the supplier |
| Documentation | Current, in the repository, written for a stranger | None, or out of date |
| Pipeline | Standard platform build; anyone can deploy | Custom tooling on the supplier’s machines |
| Hosting | The client’s account on a public platform | The supplier’s server or reseller account |
| Knowledge | Explained monthly; an internal owner who understands | The supplier is the only one who knows |
| Exit | Described in writing, with a hand-over process | Never discussed |
What it changes in how we work
- Standard technologies chosen for how many people know them, not for how clever they are.
- A named holder for every account from day one, written down, with access granted per person and removable.
- Structured content so words and images are never trapped in a layout.
- Setup as files in the repository, with the few dashboard-only settings documented.
- Documentation written for a stranger, updated with every change.
- A written explanation of what changed and why, kept with the project, so an internal owner understands the site.
- A takeover test when the documentation changes materially, with someone who has never seen the project.
- An exit process written into the agreement, with what is handed over and when.
Why it is good for us too
A client who stays because leaving is hard is a client who resents the arrangement and leaves badly the moment they can. A client who could leave any month and stays is a client who values the work, and that is the relationship worth having. The standard also keeps our own work honest: a site built to be handed over is built cleanly, documented properly and explained regularly, which is how good work is done anyway. And every site handed over well to a successor is a business that speaks well of us afterwards.
What this means for you
Measure your website, and your partner, by how easily you could leave: code in your repository, accounts in your name, structured content, setup in files, documentation for a stranger, a standard pipeline, an exit described in writing. A site that passes is yours; one that fails belongs to whoever built it. Ask your partner to describe how you would leave, and treat the quality of the answer as the quality of the relationship.
Frequently asked questions
Why would a supplier design for being left?
Because the alternative is designing for dependence, and dependence is a poor foundation for a relationship. A site the client can take anywhere has to be built on standard technologies, in the client's accounts, with documented setup and structured content, which is also what makes it fast, secure and cheap to change. The client stays because the work is good, and the standard keeps us honest about that every month.
What does portable actually mean for a website?
The code is in a repository the client owns, on widely used frameworks and platforms that any competent developer knows. Every account has a named holder, written down, and any layer the supplier holds transfers to the client on request. Content is structured and exportable. The setup, redirects, headers, environments and DNS, is written in files. There is documentation a stranger could follow. There is nothing that runs only on our infrastructure or only in our heads.
How would we test this with our current partner?
Ask them to describe, in writing, how you would leave: what you would take, from where, what a new partner would need, how long it would take. A clear, short answer with a list of accounts and a pointer to documentation means you own your site. A vague answer, a mention of proprietary systems, or a change of subject means the site is theirs in every way that matters.