Picture a Communications Director certain she needs a complete rebuild. She has a quote in hand and a board paper half written.

Ask what problems she is actually trying to solve, and she lists four: outdated content, accessibility gaps, a missing safeguarding policy, and stakeholder navigation nobody can agree on.

Three of the four are correctable on the site she already has. The fourth is not a design problem at all. It is a governance decision the board has never taken, and no rebuild would take it for her.

She is about to buy an architectural answer to what are, mostly, editorial and operational questions.

The opposite happens too. An organisation patches at a governance gap that no patch can close, pays for the same fix again and again, and rebuilds anyway.

In my work on nonprofit websites, the rebuild-versus-remediate decision almost always turns on one thing: whether the failures are architectural, technical, or editorial. Each needs a fundamentally different intervention, and the three are routinely confused with one another.

Why organisations make the wrong call

Most nonprofits approach website problems with one of two reflexes.

Reflex 1: "We need a complete rebuild."

Triggered by:

  • Stakeholder complaints about the website
  • A visual appearance that feels dated
  • The board questioning whether the site is working
  • New leadership wanting a fresh start
  • A platform that feels old

Result: significant investment rebuilding infrastructure to solve problems the infrastructure was never causing.

Reflex 2: "We'll just fix this bit."

Triggered by:

  • Limited budget for major work
  • Fear of disruption from a full rebuild
  • Hope that incremental improvements accumulate
  • Uncertainty about what the proper solution would involve

Result: money spent patching governance gaps that require architectural solutions, compounding each time the problem returns.

Both reflexes skip the only question that matters: what kind of problem is this, and what kind of intervention does that kind of problem need?

For a charity, that is not only a practical question. Charity Commission guidance on what being a trustee involves names managing resources responsibly among the six main trustee duties, and tells trustees not to take inappropriate risks with the charity's assets and to take appropriate advice when it is needed. Authorising a major capital spend on a website to solve a problem that an editorial calendar would have solved is a resource decision, and it is one trustees are expected to be able to defend.

Three categories of problem, three different answers

I categorise website problems into three types, and they require different solutions.

Category 1: Governance architecture problems (a rebuild)

What these are: fundamental architectural issues where the website cannot accommodate institutional governance requirements, regardless of content updates or technical fixes.

Examples:

  • Stakeholder navigation that creates recurring conflict because the architecture encodes a single-audience assumption
  • A multi-affiliate federation with no framework coordinating brand and standards
  • Safeguarding protocols that cannot be implemented within the current structure
  • Board oversight requiring a documentation structure that does not exist
  • Accessibility failures inherent to the templates or structural choices

Why remediation fails here: patching an architectural problem produces recurring cost without ever resolving the constraint underneath it.

What a rebuild provides: an architecture that embeds governance requirements into the foundation, including a stakeholder navigation framework, accessibility by default, safeguarding protocols and board oversight mechanisms.

The shape of the spend: a single capital item with a defined end. It is the most expensive of the three answers, and the only one that changes what the site is capable of.

Decision indicator: if you have paid for the same fix more than twice and the problem keeps returning, you are looking at architecture, not implementation.

Category 2: Technical implementation problems (remediation)

What these are: specific technical failures where the architecture is sound but the implementation has gaps, errors or omissions that can be corrected without rebuilding the foundation.

Examples:

  • Accessibility violations from colour contrast, missing alternative text or unlabelled form fields, rather than from template-level limitations
  • Broken functionality from plugin conflicts, outdated code or configuration errors
  • Performance problems from unoptimised images, excessive scripts or server configuration
  • Mobile issues caused by specific CSS faults rather than by the underlying layout system
  • Search visibility gaps from missing metadata or weak content structure

Why a rebuild is wasteful here: the architecture is not the problem. Specific implementation faults need correcting.

What remediation provides: targeted fixes against a written list, leaving a sound foundation in place.

The shape of the spend: priced from the list, which means the list has to exist before anyone can quote for it. A remediation brief that says "make it better" will be quoted like a rebuild.

Decision indicator: if the problems are specific and identifiable rather than structural, remediation is appropriate.

Category 3: Content and maintenance problems (neither)

What these are: issues stemming from outdated content, inadequate maintenance or missing operational process, rather than from architecture or implementation.

Examples:

  • Information out of date because nobody maintains it on a schedule
  • Governance documents that exist elsewhere but were never published to the site
  • Weak content because there is no editorial process or expertise behind it
  • Broken links accumulated through staff turnover and lost institutional knowledge
  • Inconsistent updates across different sections

Why infrastructure work is wasteful here: the infrastructure is fine. The operating model is not.

What is actually needed: content updates, an editorial process, maintenance protocols, staff training, and publication of the governance documentation you already hold.

The shape of the spend: mostly staff time rather than supplier invoice, and a recurring commitment rather than a project.

Decision indicator: if the architecture and implementation are sound but the content is poor or outdated, the answer is operational improvement, not infrastructure.

The diagnostic sequence

When conducting Blueprint Audits I work through four steps before making any recommendation.

Step 1: Identify and categorise the problems

"What specific problems are you experiencing?" Not vague dissatisfaction, but concrete issues: stakeholder conflict, compliance failures, technical barriers, outdated content.

"How long have these problems existed?" Long-standing, recurring issues suggest architecture. Recent problems suggest implementation or maintenance.

"What have you already tried?" Multiple failed remediation attempts suggest architectural inadequacy. No attempts at all suggest maintenance gaps that have never been tested.

"Who is affected, and how?" Board governance issues point at architecture. User experience problems point at implementation. Internal team frustration points at process.

Step 2: Establish the root cause of each problem

Architectural causes: a stakeholder navigation framework that does not exist structurally; compliance requirements that cannot be met within the current templates; safeguarding protocols the platform cannot support; board oversight needing a documentation structure that was never built; multi-stakeholder complexity exceeding a single-audience architecture.

Technical implementation causes: accessibility violations from correctable code and design faults; performance problems from fixable technical choices; functionality gaps from configuration or development errors; responsive failures at the component level; metadata and structure gaps.

Content and maintenance causes: information out of date because the maintenance process fails; quality problems from missing editorial expertise; documentation that exists but is unpublished; inconsistency from unclear content ownership.

Step 3: Test whether the intervention can actually work

For architectural problems, can remediation solve this? Usually not. Governance architecture cannot be patched. The exception is where governance documentation is the only gap and the architecture can accommodate it as content rather than as structural change.

For technical problems, can remediation solve this? Usually yes. The exception is where the platform itself is inadequate rather than merely poorly implemented.

For content and maintenance problems, can either solve this? No. Neither remediation nor a rebuild creates an operating process. The exception is where architectural change makes maintenance materially easier, in which case a rebuild can carry an operational improvement alongside it.

Step 4: Compare total cost over the planning horizon, not headline price

This decision is almost never won on the quoted price, because both remediation and a rebuild are priced from a scope that has not been established yet. Compare three columns over the same period, ideally the length of your current strategic plan.

  • Do nothing. Recurring fixes, staff hours spent on workarounds, and the cost of the things the site currently prevents you from doing.
  • Remediate. The scoped fix list, plus the maintenance that follows it, plus an honest note of what the architecture will still not let you do afterwards.
  • Rebuild. The build, plus the care it needs afterwards, minus the workaround time you get back.

Two things make this analysis honest rather than decorative. Staff workaround time is real money and is usually the largest hidden number, so count it. And the "do nothing" column has to include opportunity cost, not only invoices.

Budget the ongoing care explicitly, whichever option wins. The Charity Digital Skills Report 2026 found that only 17% of charities received digital funding from grantmaking trusts and foundations, down from 30% the year before. That funding pattern is a large part of why digital infrastructure gets funded as an occasional capital project and starved in between, and why sites reach the state where a rebuild looks like the only option left.

The misdiagnoses I see most often

Misdiagnosis 1: assuming a rebuild when remediation would do

Presenting complaint: "Our website is old and needs replacing."

Actual problems: some accessibility gaps, out-of-date content in several sections, missing governance documents, slow pages.

Diagnosis: targeted technical fixes plus a content update address all four. The architecture is sound.

What would have happened: a full rebuild bought to solve problems that a fix list and an editorial plan would have solved.

Why the misdiagnosis happened: the visual appearance felt dated, which created the assumption that the foundation needed replacing when only the implementation needed correcting.

Misdiagnosis 2: attempting remediation when a rebuild is required

Presenting complaint: "Can you fix our stakeholder navigation?"

Actual problem: the architecture encodes a single-audience assumption. Multi-stakeholder complexity cannot be accommodated within it, however the content is reorganised.

Diagnosis: the navigation framework has to be rebuilt. No amount of menu restructuring fixes a structural limitation.

What happens instead: round after round of navigation work, none of which can solve the constraint, followed by the rebuild anyway. The organisation pays for the rebuild plus every failed attempt at avoiding it.

Why the misdiagnosis happened: the hope that a cheaper intervention would work, and reluctance to acknowledge that the larger investment was the only one that could.

Misdiagnosis 3: rebuilding when the problem is operational

Presenting complaint: "Our website always has outdated information."

Actual problem: staff turnover has cost the organisation its institutional knowledge. No editorial process ensures content stays current. Maintenance responsibilities are undefined.

Diagnosis: operational improvement, meaning content ownership, an editorial process and maintenance protocols. The infrastructure is fine.

What happens instead: a rebuild that produces new infrastructure with the same operational gaps. The content drifts out of date again, because nothing that caused the drift has changed.

Why the misdiagnosis happened: the assumption that a technology solution can solve a process problem. New infrastructure does not create missing processes.

The hybrid: a targeted rebuild

Sometimes the right answer is a partial rebuild that addresses a specific governance gap while preserving infrastructure that is working.

When this applies:

  • The overall architecture is sound
  • A specific governance inadequacy exists, for example missing safeguarding infrastructure
  • A targeted architectural addition solves it
  • A full rebuild would be over-investment

Example: an existing site has workable stakeholder navigation, accessible templates and board oversight. What is missing is safeguarding infrastructure for beneficiary consent and dignity in storytelling. Adding that architecture is the whole job. Replacing everything around it is not.

Five tests to work through in order

Answering yes to a single rebuild indicator does not settle the question. The pattern across all five is what tells you where you are.

1. Can your team publish and update content independently? If yes, the CMS architecture is working. If routine updates require a developer or an external supplier, the architecture is a constraint, and improving content on top of a broken workflow will not solve the underlying problem.

2. Can your primary stakeholders find what they need in three clicks? Test it with your top three stakeholder groups. If institutional funders can reach your annual report, governance documents and impact data quickly, the navigation works. If they cannot, you have an information architecture problem that may exceed what a fix can deliver.

3. Are the accessibility failures element-level or structural? Run an automated scan first, choosing from the W3C's list of web accessibility evaluation tools, several of which are free browser extensions. Expect a long list: the WebAIM Million 2026 analysis detected WCAG 2 A or AA failures on 95.9% of the top million home pages, averaging 56.1 errors per page. The useful signal is not the count but the kind. WebAIM found 96% of all detected errors fell into six categories: low contrast text (on 83.9% of pages), missing image alternative text (53.1%), missing form input labels (51%), empty links (46.3%), empty buttons (30.6%) and missing document language (13.5%). Every one of those is element-level and correctable on the site you already have. If that is what your scan returns, accessibility is not an argument for a rebuild. If instead the heading hierarchy is broken across every template, keyboard focus is managed nowhere, or the page structure puts WCAG 2.2 Level AA out of reach without rewriting the templates, the framework itself is the problem. One caution: no automated scan proves conformance. It finds a subset of failures, and the rest requires manual testing.

4. Is the platform actively maintained and supported? Check when the last platform update was applied, whether security patches are current, and whether the original developer or agency is still reachable. If the answer to any of those is no, every future fix carries compounding risk.

5. Does the site reflect the organisation you are today? This is the strategic question. If your programmes have fundamentally changed, if your income has moved by an order of magnitude, if your stakeholder landscape has shifted, the site may be technically sound and institutionally out of date. It is the hardest of the five, because answering it means judging honestly whether the gap can be closed with content and design or whether the structure assumes a different organisation.

Four further questions consistently expose the answer when the five tests are ambiguous.

"If you corrected your top three problems, would the site serve the organisation for the length of your current strategic plan?" If yes, the problems are remediable. If no, the inadequacy is architectural.

"Have you tried to fix these problems before, and what happened?" Failed attempts point at architecture. No attempts mean you have not yet tested whether fixes work.

"Are the problems getting worse, or holding steady?" Worsening suggests architecture that cannot accommodate institutional growth. Steady suggests fixable implementation or maintenance issues.

"Would new leadership inheriting this site be able to govern it?" If no, the gaps are architectural. If yes, they are implementation or content.

When a fix is the right answer

A fix is appropriate when the platform and architecture are sound but the implementation has gaps. Specifically:

The platform is still supported and maintained. If the foundation is actively maintained and patched, it is not the problem. Outdated content, weak navigation and element-level accessibility failures can all be addressed without rebuilding.

The CMS structure matches how your organisation actually works. If your content types, such as programmes, team members, news and resources, are already represented in the CMS and your team can update them, the architecture is doing its job. The content inside it may need attention. The structure does not need replacing.

Performance issues are isolated. Slow pages caused by uncompressed images, render-blocking scripts or third-party embed bloat can be fixed in place. These are maintenance problems, not architectural ones.

Accessibility failures are specific, not systemic. Missing alternative text, contrast failures on particular elements and form labelling faults can be remediated on the existing site. If the heading hierarchy is correct and keyboard navigation works structurally, the framework is sound and individual elements need correcting.

The original build followed standards that are still current. If the site was built properly against the standards of its day and those standards have not moved underneath it, targeted improvements will deliver more per pound than starting over.

When a rebuild is the right answer

A rebuild is appropriate when the architecture itself is the constraint, and the problems cannot be solved by improving what exists because the foundation does not support what the organisation needs.

The platform is end-of-life or unsupported. A deprecated platform, an abandoned theme, or a custom build whose original developer has gone and whose code is undocumented: maintenance becomes progressively more expensive and more risky, and every fix introduces new fragility.

The CMS does not match how the organisation works. If programme staff cannot update their own content, if adding a team member requires a developer, if campaign pages take weeks because the CMS was never designed for them, these are architectural failures. No amount of content improvement fixes a structure that forces the wrong workflow.

Accessibility failures are systemic. If the heading hierarchy is broken across every template, if focus is never managed, if the site was built with no accessibility consideration at all, correcting the same class of fault on every page of every template can cost more than rebuilding on a foundation that is accessible by default. The difference matters: an accessible foundation makes conformance the normal outcome of publishing, while remediation on an inaccessible one makes it a permanent manual tax.

The site cannot serve the organisation's primary stakeholders. If institutional funders cannot find governance documents, if beneficiaries cannot navigate to programme information, if the architecture was organised around internal departmental structure rather than stakeholder need, that is an information architecture problem requiring rethinking, not patching.

The site has accumulated years of technical debt. Plugin conflicts, abandoned integrations, redirect chains, duplicate content, orphaned pages still ranking in search: when the remediation list exceeds what the site is worth, starting clean is more efficient.

A significant organisational change has occurred. A merger, a rebrand, a fundamental strategic shift, or new leadership with a materially different view of how the organisation communicates. The site then needs to reflect a new institutional reality rather than an incremental improvement of the old one.

The third option: maintain and monitor

Sometimes the right decision is neither. It is to maintain what you have while monitoring for the threshold that would trigger intervention later.

When this is appropriate:

  • The site serves institutional needs reasonably well, with no critical governance gaps or compliance failures
  • Problems exist but do not create institutional risk, and workarounds are tolerable
  • Governance frameworks are not yet board-endorsed, a leadership transition is imminent, or strategic direction is under review
  • Resources are better directed to programme work this year

The investment: minimal, meaning ongoing content maintenance and minor updates.

The triggers to monitor: stakeholder satisfaction declining, compliance gaps starting to create institutional risk, funder credibility concerns emerging, board questions about the site intensifying.

Write the triggers down. A decision to wait that is recorded, with the conditions that would reopen it, is a governance decision. The same decision left unspoken is drift.

Taking the decision to your board

Boards do not need to approve website fixes. That is operational. Boards need to understand and approve a decision to rebuild, because it commits significant expenditure and organisational capacity.

Frame the recommendation around three things: what the current site cannot do that the organisation needs, what the institutional risk is if nothing changes, and what the investment looks like over the planning horizon for the recommended path. Avoid framing the conversation around design preference, competitor comparisons or technology trends. Boards respond to governance risk and institutional credibility, not to arguments about aesthetics.

Accessibility is the clearest example of how to state risk properly. Section 29 of the Equality Act 2010 applies the duty to make reasonable adjustments to service providers, and for service providers that duty is anticipatory: you are expected to have thought about access before a disabled person arrives, not after they complain. A board told that the site cannot reach WCAG 2.2 AA without structural change has been told something about legal exposure, not about design taste.

If the recommendation is to fix rather than rebuild, the board still benefits from knowing the decision was taken deliberately. A short briefing note saying "we assessed the website against these criteria and concluded that targeted improvements address the identified gaps more efficiently than a full rebuild" demonstrates the same governance rigour as the larger decision, at less cost. It also means that when the question comes back, there is a record of why it was answered this way the first time.

What a diagnostic engagement looks like

If you are genuinely uncertain, and reasonable people in your organisation disagree about whether to fix or rebuild, the answer is not to guess. It is to run a structured diagnostic before committing resources in either direction.

The Blueprint Audit exists for this. It assesses the current site against stakeholder needs, technical requirements, accessibility obligations and governance expectations, then produces a board-ready report with a specific recommendation and the evidence behind it.

The audit stands alone. The fee is payable whatever the audit concludes, there is no obligation to proceed to implementation, and the report belongs to your organisation regardless of what comes next. That structure is deliberate. A diagnostic that is credited against the work it recommends gives whoever writes it a reason to find work that is not there. If the finding is that targeted fixes will solve the problem, the report says so, because credibility comes from honest recommendations rather than from steering towards the most expensive option.

Uncertain whether your website problems require a rebuild, remediation, or neither? The audit categorises the problems, establishes the root causes and recommends an intervention, so that the decision is made from evidence rather than from whoever complained most recently.

Further reading: