The Short Answer

Your website keeps running only while the accounts behind it are paid and reachable. If the domain, hosting, CMS and code are in the developer's name, they are the developer's, and renewal notices go to their inbox. If they are in the charity's name and documented, a new developer can take over. Own every account and write it down.

What Actually Happens, Account by Account

A website is not one thing that a developer holds or hands back. It is several separate accounts, and each fails in its own way when the person managing it goes.

  • The domain. It renews annually or on a longer term, and the renewal notice goes to whatever email address the registrar holds. If that is the developer's, nobody at the charity sees the warning, and a lapsed domain takes the website and any email on it down together.
  • Hosting. The site lives on a server someone pays for. If the hosting is on the developer's or agency's account, it stops when their billing stops or their business closes, and you cannot log in to retrieve anything.
  • The CMS. If only the developer has admin access, staff may still be able to edit pages, but nobody can add users, change settings or recover the account.
  • The code and design files. A live website is not the same as its source. Without the code repository and design files, a new developer rebuilds rather than continues.
  • Everything connected to it. Analytics, the donation processor, the email marketing platform and any forms that collect personal data each have their own account, and each needs an owner who is still there.

When all of these are in the charity's name, a developer leaving is an inconvenience: you brief someone new. When they are not, it is a recovery exercise, and the cost is time spent proving to each provider that the organisation is who it says it is.

Who Holds the Credentials

This is the inventory to complete while the developer is still reachable. It combines ownership and a way to check it without relying on anyone's word.

Asset Who Should Own It How to Verify Risk if "No" or "Unsure"
Domain registration The organisation Log in to the registrar; check the registrant and the renewal email address Critical
Hosting account The organisation Log in directly; confirm billing is to the organisation Critical
CMS admin credentials At least two staff members Test login independently of the developer Critical
SSL certificate Organisation or its host Confirm who is responsible for renewal High
Code repository The organisation Receive the full codebase, not just access to the live site High
Design files The organisation Receive the source files High
Backup The organisation Hold an independent, recent copy of the site High
Analytics access The organisation Log in to GA4 independently Medium
Email marketing integration The organisation Confirm list ownership and platform access Medium
Payment processor The organisation Confirm a direct account relationship with the processor High
Documentation The organisation A written account of how the site is structured and maintained High

Every "No" in the second column is a place where the developer leaving becomes your problem rather than theirs.

The Rights You Already Have

Two rights exist whatever your contract says, and both depend on the records being right.

The domain. For a .uk domain, transfer is a defined right rather than a favour: under Nominet's .UK Inter-registrar Transfer Policy, version 2026-03 the losing registrar must give the registrant the transfer authorisation code within five days at no charge, and ICANN's Transfer Policy sets the same five-day limit for .org. The right belongs to whoever is the registrant on the record, which is why that record has to be the organisation. If a developer registered the domain in their own name, the right is theirs.

Your data. Where a developer or agency handles personal data for you (form submissions, donor records, a mailing list) it is your processor, and UK GDPR Article 28(3)(g) requires the contract to say that at the end of the service the data is deleted or returned, at your choice (ICO: what needs to be included in the contract). When a developer leaves, ask which one happened, and get the answer in writing.

What to Ask For Before They Go

A developer may well cooperate with a handover, but they won't volunteer information you don't ask for. Request, formally and in writing:

  • all credentials in a documented format;
  • confirmation of who owns the domain and hosting, and how to transfer them;
  • the full code repository and design files;
  • a written summary of the site's architecture and any custom development;
  • a list of every third-party service the site depends on, with renewal dates and costs;
  • confirmation of what has happened to any personal data they held for you.

If a developer is uncooperative with this, that is itself important information, and a reason to resolve ownership now rather than when something breaks. If you are replacing the site rather than keeping it, the fuller process is in planning a website handover before a rebuild.

If the Developer Has Already Gone

Start by finding where each account sits. A public lookup (Nominet's for .uk, ICANN Lookup for .org and .com) names the domain's registrar, even though it will not name the registrant. Finance records show who has been paying for hosting and renewals, and old mailboxes show who has been receiving the notices.

Then go to each provider with proof of the organisation's details and ask to correct the account holder. Take an independent backup the moment you regain access to anything. Bring in a new developer to document the site before they change it: the first job is understanding what exists, not improving it.

The Handover Your Developer Can't Give You

Even a cooperative handover has limits. A developer can transfer credentials and write documentation. They can't transfer the institutional knowledge about why certain decisions were made, what breaks if you update X, or why that particular plugin is configured that way. That knowledge was never documented because it never needed to be, until now.

This is why continuity planning needs to happen before a transition, not during one.

How Dependency Builds Without Anyone Noticing

It rarely happens through a deliberate decision. It accumulates through reasonable-seeming choices over time. A freelancer builds the site because they were affordable and available. Then they become the only person who knows the login credentials. Then the plugins they chose require their specific knowledge to update safely. Then the hosting is on their account. Then the organisation has been in this arrangement for years and nobody has thought to question it.

By the time the dependency is visible, it's load-bearing.

What It Looks Like When Nothing Was Handed Over

Picture the outcomes that make this a governance question rather than an IT one. The domain lapses because renewals were going to the developer's email. A plugin breaks and nobody can fix it. The site goes down during the annual fundraising campaign. A funder tries to verify the charity's governance information and gets a 404. None of these needs a developer to behave badly; each needs only that the developer is no longer there.

This Is a Governance Risk, Not a Technology Problem

If the website is hosted, maintained and managed by a single agency or freelancer, the organisation has concentrated its web infrastructure risk in one supplier relationship. What is the contractual arrangement? What happens to the site if the agency closes? What is the notice period, and what does the site look like during a transition?

These questions belong on the risk register, with the same rigour applied to any other critical supplier. The Charity Commission's risk guidance already lists dependency on a key supplier among the operational risks trustees are expected to identify and mitigate (CC26, updated 2026), and its suggested mitigation includes service level agreements. The website is usually one supplier among several; an annual vendor risk audit covers the rest.

Operating a critical system without a continuity plan would not be acceptable for financial systems, HR records or safeguarding documentation. Websites somehow get treated differently, right up until the moment they don't work.

The same applies to the size of the supplier. An agency can close as easily as a freelancer can leave, and a one-person practice is a key person risk by definition. The answer is not to avoid small suppliers but to ask every supplier where its continuity arrangements are written down, and to check that they cover access, data and a named fallback. Mine are set out on the Blueprint Audit page.

What Dependency Costs While the Developer Is Still There

Dependency costs money before anyone leaves, in ways that rarely appear as one line item.

  • Staff time spent waiting. When a content update requires a developer, every update enters a queue: drafted internally, sent across, scheduled, published days or weeks after it was written.
  • Emergency fixes. When something breaks (a plugin conflict, a broken donation form, a site going down) the cost is the developer's emergency rate plus the disruption. A donation form that breaks mid-campaign costs gifts as well as fees.
  • Delayed communications. Campaigns that launch late because the website wasn't ready, event pages that go up after the event was promoted, press releases with no page behind them.

To size it for a Board paper, total the direct costs (hosting, domain, licences, retainer or project fees), staff hours spent waiting multiplied by their hourly rate, the number of emergency interventions multiplied by the developer's rate, and the campaigns affected by delay. The figures will be your own; the point is that they are countable.

Platform Choice Is a Governance Decision

Some platforms create dependency by design. WordPress, without deliberate structural choices, accumulates plugin debt, bespoke code and institutional knowledge that lives in the heads of whoever built it. Every customisation adds a dependency. Every plugin update is a potential breaking change that requires someone who understands the specific configuration.

Platforms that prioritise team independence (where content teams can publish, update and manage without touching code) reduce key person risk structurally. This is one of the primary governance reasons organisations move from WordPress to managed platforms like Webflow: not because of features, but because of who needs to be in the room for the site to function.

An operationally independent website is one where your team can publish content, update programme information, launch campaign pages and manage basic site changes without contacting a developer. Developers are engaged for structural work (new functionality, significant design changes, integrations), not for updating a bio or changing a phone number. When a developer leaves a site like that, the day-to-day carries on.

Building Independence Into the Infrastructure

The goal is a website where the organisation owns the asset entirely: credentials, hosting, domain, documentation, and the ability to make common changes without specialist help. This doesn't mean never using developers. It means the organisation functions when they're not available.

A Blueprint Audit maps this across your own site, as part of a full governance diagnostic.

Further Reading