A list circulates on LinkedIn every few months: five questions to ask before hiring a web agency. It is a good list. It cuts past portfolios and case studies to something more useful. Does this partner build a website, or do they build a system your own team can run?

It was not written for charities. It should have been.

Trustees carry a duty to manage the charity's resources responsibly and avoid exposing its assets, beneficiaries or reputation to undue risk (Charity Commission, The essential trustee, CC3, updated September 2026). A website nobody in the building can change, on accounts nobody in the building holds, is that kind of exposure. It does not look like a risk on launch day. It looks like a risk later, when the one person who can make the change is unavailable, expensive or gone.

So: five questions to ask before you sign anything. For each one, what a good answer sounds like, what an evasive answer sounds like, and what it costs you if you never ask.

There is an obvious problem with a web partner telling you how to interrogate web partners, and the only honest way round it is to make sure the list costs me something. Question 2 does. If you put it to me and I answer it properly, you keep the ability to replace me. That is the point of asking it.

1. "Who updates the site six months after launch, and what can my team do without calling you?"

What a good answer sounds like. A specific division of labour, offered without prompting. Your team owns everything routine: pages, posts, team bios, event listings, resource libraries, through structured CMS collections with guardrails that keep the design intact. The supplier keeps only what genuinely needs a specialist, which is platform and dependency updates, security, performance and larger structural changes.

Ask for evidence, not a promise. "Show me a project where the client added thirty or more pages after launch without your team touching it." Someone who builds systems has that example ready. Someone who builds pages will tell you about a client who "preferred us to handle it".

What an evasive answer sounds like. "Just send your changes over and we will take care of it." That is a maintenance retainer wearing the costume of a service, and it is a recurring cost dressed as a convenience. Hesitation is the same answer, more slowly.

What it costs you. A communications lead who has to email a supplier to correct a typo stops correcting typos. Programme pages go stale, a trustee list stays out of date, and by the time anyone notices how far the site has drifted from the organisation, the fix has been rebranded as a redesign.

How I answer it. Your team, from day one. I stay on for the specialist work where that is wanted, under a Monthly Partnership, but the routine publishing belongs to you and I would rather you never needed to ask me for it.

2. "What do I own, and what happens the day I stop working with you?"

This is the question I would least enjoy being asked, which is why it goes second. Ask it in four parts, because suppliers who are vague on one are often precise on the others.

The domain and the DNS. Whose name is on the registration, and whose account holds it? When a domain sits in an agency's account, the account holder controls it, and you cannot act on your own address without their cooperation. Register it in an account the organisation owns, before anyone offers to do it for you as a favour.

The accounts. Hosting, CMS, analytics, forms, email. The organisation should hold each one, with the supplier added as a user who can be removed. Not the reverse.

The work itself. Design files, content model, code, documentation. Once the invoices are paid, it should all be yours, and the contract should say so in those words rather than leaving it to be inferred.

The personal data. A supplier handling form submissions, donor records or a mailing list on your behalf is acting as your processor. UK GDPR Article 28(3) already requires a written contract, and the ICO sets out the terms that contract has to contain. Among them are end-of-contract provisions, under which the processor must, at your choice, delete or return all the personal data it has been processing for you and delete existing copies unless UK law requires otherwise. The same contract has to let you audit, and it has to stop a supplier bringing in a sub-processor without your authorisation. None of this is a favour I am recommending you ask for. It is the minimum the law already expects of the contract you are about to sign, and a supplier who has never been asked for it is telling you how their other clients are set up.

What an evasive answer sounds like. "It is all in our account, but you can have it whenever you want." "We would never hold a client hostage." Both may be sincere, and neither is a contract term. Goodwill is not portable across a staff change at the agency.

What it costs you. A migration nobody budgeted for, at the worst possible moment, usually during a rebrand or a funding round. Single-supplier dependency is the kind of thing a vendor risk review of a charity's web infrastructure exists to surface, and it is rarely created in one decision. It accumulates quietly, one convenience at a time.

How I answer it. Everything is yours, and the exit is written down before the work starts rather than negotiated at the end. Domain, DNS, hosting, CMS and analytics live in accounts the organisation owns. What I produce is yours on final payment. If the engagement ends, you keep the site, the content model and the documentation, and I write down where everything lives and hand over the access. There is no lock. Planning the handover at the start rather than at the end is what makes that real, and it costs nothing to agree while everybody is still pleased with each other.

3. "What standard do you build to, and how will you show me you hit it?"

Two standards on a charity website have published numbers attached, which means a supplier can be held to both and has no room to be vague about either.

Accessibility. WCAG 2.2 has been a W3C Recommendation since 5 October 2023, and it defines three conformance levels: A, AA and AAA. Level AA is the level many organisations aim for, and it means every Level A and Level AA success criterion is satisfied. That is a testable claim about specific criteria, not a general aspiration, and it is the standard I work to. Treat "fully accessible" and "100 per cent compliant" as warning phrases: conformance is assessed criterion by criterion, and it degrades the moment somebody publishes an image without alternative text. What matters at least as much as the build is who can break it afterwards.

Performance. Google publishes thresholds for the Core Web Vitals: Largest Contentful Paint within 2.5 seconds, Cumulative Layout Shift of 0.1 or less, and Interaction to Next Paint of 200 milliseconds or less. The part suppliers skip is how those thresholds are assessed, which is at the 75th percentile of page loads, segmented across mobile and desktop. Your audiences are not all on a new laptop in a UK office. A programme officer on a phone in Nairobi and a journalist on hotel wifi are inside that 75th percentile too, which is exactly why the measurement is defined that way and why a green score on launch day is a lab result rather than evidence.

What an evasive answer sounds like. "We follow best practice." "It will be fast, and it will be accessible." Neither is a number, and a supplier with no number is not measuring.

What it costs you. Remediation billed as a project, after you paid for the thing that should have met the standard the first time.

4. "If our positioning changes in eighteen months, is that a restructure or a rebuild?"

What a good answer sounds like. "It depends on the foundation, and here is how I would build it so that it is a restructure." A site constructed on a defined content model, with a modular component library and a CMS that separates structure from presentation, can absorb a repositioning as a restructure: new messaging, new visuals, some new templates, on the same foundation. A site built as a collection of bespoke pages, with content and layout decisions hard-coded into each one, is a rebuild. Possibly from scratch.

What a good answer does not contain is a timeline. Nobody can give you one before the scope exists, and a supplier who offers a schedule for work that has not been defined is guessing in a way that will be used against you when the guess turns out to be wrong.

What an evasive answer sounds like. A flat quote, produced without a single question about how you publish, who publishes, or what the site has to carry next year. A quote given on no information is a quote for whatever you described that afternoon.

What it costs you. Buying the same website twice, and being told the second time that the first one "had run its course". Whether you are actually facing a rebuild or a repair is a decision worth taking deliberately rather than accepting from whoever is quoting.

5. "What do you delete that other vendors leave in?"

Strong partners have opinions about what should not be there. Weak ones say "we build what you ask for", which sounds accommodating and is in fact a refusal to advise.

Here is what I consistently argue against on charity and NGO sites.

Auto-playing carousels. Ask what slide three is for. Every slide after the first competes with the one message you needed to land, and the component has to be maintained forever by whoever inherits it.

Stock photography standing in for real work. If you work with communities, show the work. A polished image of anonymous smiling people is the visual equivalent of a sentence with no verb, and the readers you most want to impress have seen it on other sites before.

Overloaded mega-navigation. If a visitor needs a map to read your menu, the problem is the information architecture and more links will not solve it.

"Innovation" pages with nothing behind them. If you cannot point to a specific programme, publication or outcome, it is filler, and filler costs credibility with exactly the readers who check.

Motion for its own sake. Movement should direct attention. If the scroll animation is the most memorable thing about a page, the content has a problem the animation is concealing.

These are judgements, not findings, and a partner should be able to tell you which is which. What the question really tests is whether they have any.

The question behind all five

You are not buying a website. You are buying a dependency, and the useful question is how cheaply you can end it.

Write the answers down. The Charity Commission's guidance says trustees should regularly review and assess the risks their charity faces and plan for the management of those risks (CC26), and single-supplier dependency on the organisation's most public asset belongs in that review alongside everything else that would hurt if it failed at the wrong moment. Put the five answers in the file with it, dated, so the next communications lead inherits the reasoning rather than only the contract.

If you want the longer version of this, evaluating a web consultant without writing a full RFP covers the same ground at more length, including what to ask for in writing and what to test before the first invoice.