Rebuild, Fix, or Remediate: How to Decide What Your Nonprofit Website Actually Needs
Key takeaways
- Website problems fall into three categories: governance infrastructure, technical implementation, and content or maintenance.
- Governance architecture cannot be patched; remediating it wastes money before an eventual rebuild anyway.
- Sound architecture with specific technical faults needs targeted remediation, not a costly full rebuild.
- Outdated content signals an operational process problem that no amount of new infrastructure will solve.
- Repeated failed fixes and worsening problems indicate architectural inadequacy requiring a rebuild.
- Sometimes the right choice is to maintain and monitor, reassessing only when defined triggers are reached.
Summary
The language of website projects — redesign, rebuild, remediate — obscures more than it clarifies. A redesign might mean a visual refresh that leaves the underlying architecture unchanged. A rebuild might mean migrating to a new platform while maintaining the same content structure. Remediation might mean anything from fixing three broken links to a systematic accessibility overhaul. The decision about which approach to take should be based on a diagnostic assessment of what is actually failing and why, not on the language used to describe it.For established nonprofits, the most important diagnostic question is whether the current website’s failures are architectural or editorial. Architectural failures — a CMS that cannot support content governance, a platform that cannot maintain accessibility compliance, accumulated redirect debt — require architectural solutions. Targeted fixes will not resolve them. Editorial failures — outdated content, missing governance documents, accessibility violations introduced through ordinary content management — can be addressed through governance infrastructure and editorial training without a rebuild, provided the underlying architecture can support the governance framework that would prevent the failures from recurring.This post provides a structured decision framework for determining which approach is appropriate for a specific organisation’s situation: the diagnostic criteria for architectural versus editorial failure, the specific circumstances in which targeted remediation is both appropriate and sufficient, the circumstances in which a rebuild is the only path to a governable outcome, and how to document and present the decision in a way that gives the Board the governance evidence they need to authorise the recommended approach with confidence.
I recently spoke with a Communications Director convinced she needed complete website rebuild costing £18,000.
When I asked what problems she was trying to solve, she listed: outdated content, accessibility gaps, missing safeguarding policy, unclear stakeholder navigation.
I showed her that three of four issues could be remediated for £3,500 whilst the fourth required governance framework decision, not design work.
She'd nearly spent £18,000 on rebuild when £3,500 remediation plus governance clarity would solve actual problems.
The opposite happens just as often—organisations attempt remediation patching governance gaps requiring architectural rebuild, wasting money on fixes that can't work.
Through my nonprofit work building 100+ websites, I've learned that the rebuild versus remediate decision requires understanding whether problems stem from governance infrastructure absence, technical implementation failures, or content/maintenance gaps—each requiring fundamentally different interventions.
Why Organisations Make Wrong Rebuild Decisions
Most nonprofits approach website problems with one of two reflexes:
Reflex 1: "We need complete rebuild"
Triggered by:
- Stakeholder complaints about website
- Visual appearance feels dated
- Board questioning website effectiveness
- New leadership wanting fresh start
- Technology platform feels old
Result: significant investment rebuilding infrastructure that should have been built correctly from the start.
Reflex 2: "We'll just fix this bit"
Triggered by:
- Limited budget for major work
- Fear of disruption from full rebuild
- Hope that incremental improvements accumulate
- Uncertainty about what proper solution requires
Result: Money spent patching governance gaps that require architectural solutions compounds over time.
Both reflexes avoid the actual question: What type of problem exists, and what intervention does that problem type require?
The Three Problem Categories Requiring Different Interventions
After 7+ years specialising in nonprofits, I've learned to categorise website problems into three types requiring fundamentally different solutions:
Category 1: Governance Infrastructure Problems (Require Rebuild)
What these are: Fundamental architectural issues where website can't accommodate institutional governance requirements regardless of content updates or technical fixes.
Examples:
- Stakeholder navigation creating recurring conflicts because architecture encodes single-stakeholder assumption
- Multi-affiliate federation with no governance framework coordinating brand and standards
- Safeguarding protocols impossible to implement within current architecture
- Board oversight requiring governance documentation structure that doesn't exist
- Accessibility violations inherent to platform or structural choices
Why remediation fails: Patching governance infrastructure problems creates expensive recurring costs without solving underlying architectural inadequacy.
What rebuild provides: New architecture embedding governance requirements into foundational structure—stakeholder navigation framework, compliance verification, safeguarding protocols, Board oversight mechanisms.
Investment required: £12,000-£25,000 for complete governance infrastructure rebuild
Decision indicator: If you've attempted remediation multiple times (£2-5k each) without resolving problem, it's likely governance infrastructure requiring rebuild.
Category 2: Technical Implementation Problems (Require Remediation)
What these are: Specific technical failures where architecture is sound but implementation has gaps, errors, or deficiencies that can be corrected without rebuilding foundation.
Examples:
- Accessibility violations from colour contrast, missing alt text, poor form labels (not inherent platform limitations)
- Broken functionality from plugin conflicts, outdated code, or configuration errors
- Performance issues from unoptimised images, excessive scripts, or server configuration
- Mobile responsiveness problems from CSS issues (not fundamental architecture)
- Search engine optimisation gaps from missing metadata or poor content structure
Why rebuild is wasteful: Architecture isn't the problem—specific technical implementation just needs correction.
What remediation provides: Targeted fixes addressing specific technical failures without rebuilding sound underlying architecture.
Investment required:£2,000-£6,000 for comprehensive technical remediation
Decision indicator: If problems are specific, identifiable technical issues rather than fundamental architectural limitations, remediation is appropriate.
Category 3: Content and Maintenance Problems (Require Neither)
What these are: Issues stemming from outdated content, inadequate maintenance, or operational processes—not architecture or technical implementation.
Examples:
- Outdated information because nobody maintains content regularly
- Missing governance documentation that exists elsewhere but isn't published
- Poor content quality from lack of writing expertise or editorial process
- Broken links from staff turnover and lost institutional knowledge
- Inconsistent updates across different website sections
Why rebuild or remediation is wasteful: Infrastructure is fine—operational processes just need improvement.
What's actually needed: Content updates, editorial processes, maintenance protocols, staff training, governance documentation publication.
Investment required:£500-£2,000 for content updates plus ongoing operational commitment
Decision indicator: If website architecture and technical implementation are sound but content is poor or outdated, operational improvement is needed, not infrastructure work.
The Decision Framework I Use
When conducting Blueprint Audits, I use systematic framework determining appropriate intervention:
Step 1: Problem Identification and Categorisation
Questions to ask:
"What specific problems are you experiencing? "Not vague dissatisfaction but concrete issues: stakeholder conflicts, compliance failures, technical barriers, outdated content.
"How long have these problems existed? "Long-standing recurring issues suggest governance infrastructure. Recent problems suggest implementation or maintenance.
"What have you tried to fix these problems? "Multiple failed remediation attempts suggest architectural inadequacy. No attempts suggest maintenance gaps.
"Who is affected and how? "Board governance issues suggest infrastructure. User experience problems suggest implementation. Internal team frustration suggests process.
Step 2: Root Cause Analysis
For each identified problem, determine root cause:
Governance infrastructure cause:
- Stakeholder navigation framework doesn't exist architecturally
- Compliance requirements can't be met within current structure
- Safeguarding protocols require architecture current platform can't support
- Board oversight needs documentation structure that isn't built
- Multi-stakeholder complexity exceeds single-audience architecture
Technical implementation cause:
- Accessibility violations from fixable code/design issues
- Performance problems from correctable technical choices
- Functionality gaps from configuration or development errors
- Mobile issues from responsive design failures
- SEO problems from metadata or structure gaps
Content/maintenance cause:
- Information is outdated because maintenance processes fail
- Quality is poor because editorial expertise or processes missing
- Documentation exists but isn't published to website
- Inconsistency stems from unclear content governance
- Problems are fundamentally operational, not architectural
Step 3: Intervention Appropriateness Assessment
For governance infrastructure problems:
Can remediation solve this? Usually no. Governance architecture can't be patched—it requires foundational rebuild.
Exception: If governance documentation is the only gap and architecture can accommodate it through content addition (not structural change), remediation may work.
For technical implementation problems:
Can remediation solve this? Usually yes. Specific technical issues can be corrected without rebuilding architecture.
Exception: If technical platform itself is fundamentally inadequate (not just poorly implemented), rebuild may be needed.
For content/maintenance problems:
Can remediation solve this? Usually no—neither remediation nor rebuild addresses operational processes.
Exception: If architectural changes make content maintenance significantly easier, rebuild could include operational improvement.
Step 4: Cost-Benefit Analysis
For rebuild consideration:
Rebuild cost: £12,000-£25,000Alternative cost: Continuing with recurring remediation £2,000-£5,000 annually indefinitely
ROI calculation: If recurring costs over 3-5 years exceed rebuild investment, rebuild justified
For remediation consideration:
Remediation cost: £2,000-£6,000
Alternative cost: Complete rebuild £12,000-£25,000
ROI calculation: If remediation solves 80%+ of problems for <40% rebuild cost, remediation justified
For content/process improvement:
Operational investment: £500-£2,000 plus ongoing commitment
Alternative cost: Rebuild that doesn't solve operational problems £12,000-£25,000
ROI calculation: If problems are operational, infrastructure investment is wasted—operational improvement is only solution
The Common Misdiagnosis Patterns I See
Misdiagnosis 1: Assuming Rebuild When Remediation Sufficient
Presenting complaint: "Our website is old and needs replacing"
Actual problems:
- Some accessibility gaps (colour contrast, alt text)
- Outdated content in several sections
- Missing governance documentation
- Slow page load times
Diagnosis: Technical remediation (£3,500) plus content updates (£1,000) solves all problems. Architecture is sound.
What organisations nearly did: £18,000 complete rebuild addressing problems £4,500 remediation would fix.
Why misdiagnosis happened: Visual appearance felt dated, creating assumption that infrastructure needed replacing when implementation just needed improvement.
Misdiagnosis 2: Attempting Remediation When Rebuild Required
Presenting complaint: "Can you fix our stakeholder navigation?"
Actual problem: Architecture encodes single-stakeholder assumption. Multi-stakeholder complexity can't be accommodated within current structure regardless of content reorganisation.
Diagnosis: Governance infrastructure rebuild (£15,000) required. No amount of navigation tweaking fixes fundamental architectural limitation.
What organisations attempted: Three rounds of navigation remediation (£2,000 each = £6,000) that couldn't solve architectural problem. Eventually rebuilt anyway for £15,000. Total spent: £21,000.
Why misdiagnosis happened: Hoped cheaper intervention would work. Avoided acknowledging architectural inadequacy requiring larger investment.
Misdiagnosis 3: Rebuilding When Operational Process Is Problem
Presenting complaint: "Our website always has outdated information"
Actual problem: Staff turnover creates lost institutional knowledge. No editorial processes ensure content currency. Maintenance responsibilities undefined.
Diagnosis: Operational improvement (content governance, editorial processes, maintenance protocols) required. Infrastructure is fine.
What organisations did: £16,000 rebuild creating new infrastructure with same operational gaps. Content outdated again within 6 months.
Why misdiagnosis happened: Assumed technology solution could solve operational problem. New infrastructure doesn't create missing processes.
The Hybrid Approach: Targeted Rebuild
Sometimes organisations need partial rebuild addressing specific governance gaps whilst preserving sound existing infrastructure:
When this works:
- Overall architecture is sound
- Specific governance inadequacy exists (e.g., safeguarding protocols missing)
- Targeted architectural addition solves problem
- Full rebuild would be overinvestment
Example: Existing website has good stakeholder navigation, compliance verification, and Board oversight. Missing: safeguarding infrastructure for beneficiary consent and dignity preservation.
Solution: Targeted rebuild adding safeguarding architecture (£5,000-£8,000) rather than complete rebuild (£18,000) preserving functional existing governance infrastructure.
Investment: £5,000-£8,000 for targeted governance addition
The Questions That Reveal Appropriate Intervention
When I conduct Blueprint Audits determining rebuild versus remediate decisions, these questions consistently expose what intervention problem type requires:
"If we fixed your top three problems, would the website serve institutional needs for 3-5 years?"
If yes: Problems are likely remediable technical or content issues, not architectural. If no: Fundamental governance infrastructure inadequacy requiring rebuild.
"Have you attempted to fix these problems before? What happened?"
If previous remediation failed: Architectural problem requiring rebuild. If no previous attempts: May be remediable—haven't tested whether fixes work.
"Are problems getting worse over time or staying constant?"
If worsening: Suggests governance infrastructure can't accommodate institutional growth—rebuild needed. If constant: Suggests fixable implementation or maintenance issues—remediation appropriate.
"Would new leadership inheriting this website be able to govern it effectively?"
If no: Governance infrastructure gaps requiring rebuild. If yes: Implementation or content issues requiring remediation or operational improvement.
"What percentage of your dissatisfaction stems from governance gaps versus visual appearance?"
If primarily governance: Rebuild addressing infrastructure. If primarily visual: Remediation updating design within sound architecture.
The Blueprint Audit Decision Framework
This is why Blueprint Audit process specifically includes rebuild versus remediate assessment before any implementation recommendation.
The decision analysis includes:
Problem categorisation: Which issues are governance infrastructure versus technical implementation versus operational process?
Root cause analysis: Why do problems exist? What would actually solve them?
Intervention appropriateness: Can remediation address governance gaps or is rebuild required? Would rebuild solve operational problems or waste investment?
Cost-benefit calculation: What's total cost over 3-5 years for each intervention option? What's ROI?
Implementation recommendation: Rebuild, remediate, operational improvement, or hybrid approach based on actual problems requiring solution.
The output prevents expensive misdiagnosis—rebuilding when remediation sufficient or attempting remediation when rebuild required.
The Third Option: Maintain and Monitor
Sometimes the right decision is neither rebuild nor remediate—it's maintain current infrastructure whilst monitoring for threshold triggering future intervention.
When this is appropriate:
Current infrastructure is adequate:
- Website serves institutional needs reasonably well
- No critical governance gaps or compliance failures
- Stakeholder satisfaction is acceptable
- Resources better directed to programmatic work
Problems are minor or manageable:
- Issues exist but don't create institutional risk
- Workarounds enable adequate functionality
- Cost of intervention exceeds benefit
- Problems don't significantly impair mission delivery
Institutional readiness is uncertain:
- Governance frameworks not yet Board-endorsed
- Leadership transition imminent
- Strategic direction under review
- Better to wait for clarity before major investment
Investment: Minimal—ongoing content maintenance and minor updates
Monitoring triggers:
- Stakeholder satisfaction declining
- Compliance gaps creating institutional risk
- Funder credibility concerns emerging
- Board governance questions intensifying
When triggers are reached, reassess rebuild versus remediate decision.
The Core Insight
Not every website problem requires complete rebuild. Not every governance gap can be remediated. Not every dissatisfaction warrants infrastructure investment.
The rebuild versus remediate decision requires understanding whether problems stem from governance architecture inadequacy, technical implementation gaps, or operational process failures—each requiring fundamentally different interventions.
Organisations that rebuild when remediation would suffice waste £12,000-£20,000 on unnecessary infrastructure replacement.
Organisations that attempt remediation when rebuild is required waste £4,000-£8,000 on patches that can't solve architectural problems, then eventually rebuild anyway.
Organisations that invest in infrastructure when operational processes are the problem waste £15,000-£25,000 on technology that can't solve human/process issues.
The Blueprint Audit prevents expensive misdiagnosis by categorising problems, identifying root causes, and recommending appropriate interventions—rebuild, remediate, operational improvement, hybrid approach, or maintain and monitor.
When you understand what type of problem you actually have, you can invest appropriately in solutions that work rather than expensive interventions addressing wrong issues.
Uncertain whether your website problems require rebuild, remediation, or neither? The Blueprint Audit includes problem categorisation, root cause analysis, and intervention appropriateness assessment preventing expensive misdiagnosis. £2,500 for decision framework ensuring appropriate investment.
Learn more about the Blueprint Audit
Further reading:
- Hidden governance costs
- Infrastructure vs design
- Credibility audit
- Selecting governance-ready consultants
What You Take Away From the Right Examples
The value of studying nonprofit website examples isn't inspiration — it's pattern recognition. Once you can see why a particular homepage works (specific headline, clear routing, one primary action), you can apply that structural thinking to your own site regardless of your budget, platform, or design constraints.
The organisations whose websites consistently perform well share a common characteristic: every design decision was made in service of a specific audience need, not an aesthetic preference. That discipline is what separates sites that are genuinely effective from sites that merely look professional.
Why This Decision Matters More Than You Think
A rebuild that was not necessary wastes six to twelve months of organisational capacity, consumes budget that could have addressed the actual problems, and leaves the team managing a transition they did not need. A fix applied to a fundamentally broken architecture delays the inevitable and accumulates technical debt that makes the eventual rebuild harder and more expensive.
Getting this decision right is a governance responsibility. The Board should understand why one path was chosen over the other, and the reasoning should be defensible — not based on aesthetic preference or a vendor’s recommendation to pursue the option that generates the most revenue for them.
When a Fix Is the Right Answer
A fix is appropriate when the underlying platform and architecture are sound but the implementation has gaps. Specifically:
The platform is still supported and maintained. If your site is on Webflow, WordPress with current themes, or another actively maintained platform, the foundation is not the problem. Outdated content, poor navigation, or accessibility failures can be addressed without rebuilding.
The CMS structure matches how your organisation actually works. If your content types — programmes, team members, news, 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, but 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 without rebuilding. These are maintenance problems, not architectural ones.
Accessibility failures are specific, not systemic. Missing alt text, poor colour contrast on specific elements, or form labelling issues can be remediated on the existing site. If the heading hierarchy is correct and keyboard navigation works at a structural level, the framework is accessible — individual elements need fixing.
The site was professionally built within the last three to four years. If the original build followed reasonable standards and the platform has been maintained, targeted improvements will deliver more value per pound spent than starting over.
When a Rebuild Is the Right Answer
A rebuild is appropriate when the architecture itself is the constraint — when 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. If your site runs on a deprecated platform, an abandoned WordPress theme, or a custom build where the original developer is no longer available and the code is undocumented, maintenance becomes increasingly expensive and risky. 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 new team member requires developer intervention, if campaign pages take weeks to build because the CMS was not designed for them — these are architectural failures. No amount of content improvement will fix a structure that forces the wrong workflows.
Accessibility failures are systemic. If the heading hierarchy is broken across every page template, if focus management does not work at all, if the site was built without any WCAG consideration — remediation on the existing architecture may cost more than rebuilding on an accessible framework. The Lumos framework I use addresses this at the foundation level, making every page accessible by default rather than requiring manual fixes on every element.
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 site architecture was designed around internal departmental structure rather than stakeholder needs — this is a fundamental information architecture problem that requires rethinking, not patching.
The site has accumulated years of technical debt. Plugin conflicts, abandoned integrations, redirect chains, duplicate content, orphaned pages that still rank in search — when the remediation list exceeds what the site is actually worth, starting clean is more efficient.
A significant organisational change has occurred. A merger, rebrand, fundamental strategic shift, or new leadership with a materially different vision for how the organisation communicates. In these cases, the website needs to reflect a new institutional reality, not an incremental improvement of the old one.
The Decision Framework
Work through these five questions in order. If you answer yes to any of the rebuild indicators, that signal carries significant weight — but one yes does not automatically mean rebuild. The pattern across all five tells you where you are.
1. Can your team publish and update content independently? If yes, the CMS architecture is working. If no — if routine updates require a developer or external help — the architecture is a constraint, and fixing content on top of a broken workflow will not solve the underlying problem.
2. Can your primary stakeholders find what they need within three clicks? Test this with your top three stakeholder groups. If institutional funders can find your annual report, governance documents, and impact data quickly, the navigation works. If they cannot, you have an information architecture problem that may require restructuring beyond what a fix can deliver.
3. Is the site accessible at a structural level? Run an automated accessibility scan (axe DevTools is free). If you see dozens of violations but they are mostly content-level issues — missing alt text, contrast failures on specific elements — these are fixable. If you see structural failures — broken heading hierarchy across templates, no skip navigation, no focus management — the framework itself is the problem.
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 available. If the answer to any of these is no, every future fix carries compounding risk.
5. Does the site reflect the organisation you are today? This is the strategic question. If the website was built for an organisation with a £500K budget and you now operate at £3M, if your programmes have fundamentally changed, if your stakeholder landscape has shifted — the website may be architecturally sound but institutionally outdated. This is the hardest question because the answer requires honest assessment of whether the gap can be closed with content and design updates or whether the site’s structure assumes a different organisation.
How to Present This to Your Board
Boards do not need to approve website fixes — that is operational. Boards need to understand and approve the decision to rebuild, because it involves significant expenditure and organisational commitment.
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 and timeline look like for the recommended path. Avoid framing the conversation around design preferences, competitor comparisons, or technology trends. Boards respond to governance risk and institutional credibility — not to arguments about aesthetics.
If the recommendation is to fix rather than rebuild, the Board still benefits from knowing that the decision was made deliberately. A short briefing note that says ‘we assessed the website against these criteria and concluded that targeted improvements will address the identified gaps more efficiently than a full rebuild’ demonstrates governance rigour.
What a Diagnostic Engagement Looks Like
If you are genuinely uncertain — if reasonable people in your organisation disagree about whether to fix or rebuild — the answer is not to guess. It is to conduct a structured diagnostic before committing resources in either direction.
The Blueprint Audit exists specifically for this purpose. 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 costs £2,500 and stands alone. There is no obligation to proceed with implementation, and the report belongs to the organisation regardless of what comes next. If the finding is that targeted fixes will solve the problem, the report will say so — because credibility comes from honest recommendations, not from steering toward the most expensive option.
For the governance framework that sits behind this decision, see Why Your NGO Website Is a Governance Problem. For the stakeholder analysis that determines who your site should actually serve, see Nonprofit Website Stakeholder Mapping.
Frequently asked questions
A rebuild starts from scratch — new platform, new design, new architecture, new CMS structure. Remediation works within the existing site, addressing specific identified failures: improving accessibility, restructuring navigation, updating content architecture, upgrading hosting. Rebuild is the right choice when the existing platform or architecture fundamentally cannot support the organisation's needs. Remediation is appropriate when the foundation is sound but specific elements are failing. The decision should be driven by an audit, not by preference or frustration.
A rebuild is indicated when: the platform requires developer intervention for routine content tasks, the CMS architecture cannot serve stakeholder needs without starting over, the site has accumulated technical debt where fixing individual problems creates new ones, the organisation's compliance obligations cannot be met within current constraints, or the platform itself is end-of-life. If any one of these conditions is met, remediation will typically cost more and deliver less than a clean rebuild.
Well-scoped remediations address a specific set of identified failures rather than being open-ended improvement exercises: accessibility compliance, navigation restructuring, content governance improvements, performance optimisation, or CMS architecture changes. The scope should be determined by a structured audit rather than by what seems most visible or urgent. A remediation brief that says 'make it better' typically produces work that costs as much as a rebuild without the structural improvements a rebuild would deliver.
Rebuild costs for established nonprofits typically range from £15,000 to £35,000 depending on complexity, content volume, and integration requirements. Remediation projects typically range from £5,000 to £15,000 depending on scope. However, repeated remediation on a fundamentally inadequate platform often costs more over three years than a single well-executed rebuild — because each fix is more expensive than it would be on a purpose-built foundation and each fix reveals additional problems the previous one didn't address.
An independent audit is the most reliable basis for this decision because it provides an objective assessment of current technical debt, stakeholder journey effectiveness, accessibility compliance gaps, and governance failures. Without an audit, the decision is typically made on the basis of who is most vocal internally — which usually means whoever had the most recent frustrating experience with the site. An audit translates subjective frustration into specific, prioritised findings that make the decision tractable.
Yes, and phasing is often appropriate. A sensible phase structure: phase one addresses compliance, governance pages, and primary stakeholder journeys — the non-negotiable infrastructure. Phase two addresses content depth, secondary journeys, and advanced features. Each phase must be independently functional — not a partial implementation that only works when the whole project is complete. Do not phase accessibility compliance into a later phase; it belongs in phase one as a non-negotiable baseline.
A well-planned rebuild typically takes 16 to 24 weeks from project start to launch. Brief development and procurement adds four to six weeks before the project starts, so allow 22 to 30 weeks from initiating the process to going live. Agencies that promise delivery in eight to twelve weeks for a complex nonprofit site are planning to cut corners on testing, content preparation, accessibility verification, or documentation. Tight timelines consistently produce poor governance outcomes at handover.
Conduct a content audit before the rebuild begins. Identify what is current and accurate, what needs updating, and what should be retired. Carrying outdated, inaccurate, or inaccessible content into a new site is the single most common rebuild mistake and typically the most expensive to fix after launch. The rebuild is also the right moment to establish content governance — who owns each section, who approves updates, and how often each content type is reviewed. These decisions should be made before the build, not retrofitted afterwards.
Platform change should be driven by audit findings rather than trend or preference. If the current platform is causing the identified problems — WordPress plugin dependency, inadequate CMS for the team's capability, performance limitations — then platform change is justified. If problems are architectural or content-related rather than platform-related, changing platform adds migration cost and risk without addressing the actual failures. The question is not 'which platform is best?' but 'does our current platform prevent us from solving these specific problems?'
Frame it as infrastructure investment with a risk basis rather than a design project. Present specific evidence: accessibility audit score, number of outdated pages, staff hours spent on workarounds monthly, compliance gaps with quantified risk, and grant opportunities where the website created friction. Then model the three-year total cost of continuing with the current site versus investing in a rebuild. Boards that approve infrastructure investment for physical premises often need to be shown explicitly that digital infrastructure warrants the same scrutiny and the same investment rationale.
