Institutional website
risk review
For nonprofits, associations, public agencies & civic institutions.
Most institutional website failures are not design failures.
They are governance, migration, publishing, accessibility, and ownership fractures compounded quietly — rarely from typography alone.
CauseHouse maps those fractures before anyone commits scope or capital.
Built so procurement stakeholders can skim, challenge vendors, and hand material to boards without reformatting.
Audience
Who this is designed for
Procurement people self-select faster when organisational fit is explicit—not implied.
- Communications & editorial teams
- Nonprofits & associations
- Public institutions & civic organizations
- Museums & cultural nonprofits
- Housing authorities & human-services agencies
- Coalitions & multi-partner initiatives
- Procurement officers & evaluating boards
- Operational leadership (COO / CIO adjacency)
This framework reflects patterns CauseHouse observes across nonprofit, public-sector, and multi-stakeholder digital programmes — not hypothetical theory exclusively.
Institutional websites rarely collapse all at once.
They degrade through accumulated operational ambiguity.
Operational context
Most redesigns fail quietly after launch.
Symptoms surface gradually: calendars slip, redirects rot quietly, approvals get political, integrations stall upgrades—then residents, donors, or staff stop trusting what they see online.
Procurement owes leaders a skim layer that exposes structural weakness—not only creative direction.
Operational risk signals (abbreviated)
- —Only one person understands publishing.
- —Active forms undocumented — compliance exposure.
- —Accessibility handled as launch QA, then ignored.
- —Credentials and hosting concentrated outside institutional control.
- —Analytics collects data nothing operational uses weekly.
Systems depiction
Where failure travels upstream first.
Charts are aides-mémoire: where governance weakens publishing, downstream technical debt hardens silently.
Operational failure cascade
Issues visible to the public are late-stage symptoms; interruptions higher in this stack are where procurement probes first.
Who typically owns what (illustrative)
Roles always vary—use this schematic to provoke explicit assignment, not bureaucracy for its own sake.
The highest-risk redesign pitches are typically the boldest aesthetically.
Ambition compounds harm when stewardship—who publishes, who decides, who can roll back—is still undefined.
Common failure arcs
Typical institutional project failure patterns
Naming these patterns buys shared vocabulary in-room—fast language for disciplined pushback on bad sequencing.
- The overbuild
- Heavy custom tooling ships before governance, ownership, or publishing rhythms exist.
- The migration collapse
- Content cleanup postponed until deployment windows compress redirects and QA together.
- The accessibility scramble
- Audit-only mindset leaves authors unconstrained — regressions accrue silently after launch.
- The vendor lock-in
- Architecture or credentials tether teams to builders; independence never cleanly transfers.
- The approval bottleneck
- Departments multiply stakeholders without escalation routes — freezes or rogue edits follow.
Operational reality check
What institutional failure tends to feel like
Abstract risk becomes concrete inconvenience, liability, reputational abrasion, abandonment of the official channel—or all four simultaneously.
- Residents unable to locate critical statutory or intake forms.
- Donation or membership attribution breaking mid-migration without reconciliation.
- Accessibility complaints or regulatory concerns after heroics-at-launch—not before.
- Staff abandoning the CMS for unofficial fixes (PDFs, unmanaged microsites, email cascades).
- Organic discovery collapsing once redirect stewardship lapses.
- Public notices ageing because no accountable owner publishes updates.
- Vendor dependency deepening post-redesign via credentials or brittle bespoke modules.
- Interdepartmental publishing bottlenecks hardening once real volume returns.
Judgment & restraint
When we recommend against rebuilding
A redesign often amplifies — instead of cures — weaknesses when stewardship remains unmapped, publishing capacity is overstated, or migration artefacts are improvised under deadline compression.
Sometimes the conscientious posture is narrower intervention: reclaim independence, clarify ownership rails, stabilize integrations—then reconsider capital-scale redesign deliberately.
We generally avoid replacing stable operational systems unless they are substantively — and recurrently — contributing to observable failure, not merely ageing cosmetically.
Preferable precursor moves before discretionary rebuild votes:
- —Governance restructuring with clear ownership lanes
- —CMS simplification that matches staffing reality
- —Accessibility remediation with authoring guardrails baked in
- —Migration sequencing with deterministic redirect inventories
- —Publishing workflow redesign and explicit approval ladders
- —Analytics setup tied to stewardship meetings
- —Integration thinning plus a dependency registry teams can audit
- —Standardized templates that reduce authoring variance
- —Phased modernization instead of heroic replatforming
Systems we seldom replace absent fault evidence
- CRM / constituent databases
- Donations & ticketing commerce stacks
- Event ticketing & registrations
- Program or case-management databases
- Document issuance & records systems
- Member/community platforms already performing
Substitution without attributable failure loads migration labour, contractual drag, adoption risk — costs models often glide past casually.
Every score row below is skim-first.
Open one item when you want detail; otherwise treat the headings as procurement-facing guardrails, not a manifesto appendix.
Scope map
What this review covers at a glance
Twelve areas — same vocabulary we use verbally on calls and in diligence notes.
- 01Audience pathway clarity
- 02Donation, member & service journey clarity
- 03CMS dependence on developers
- 04Accessibility debt
- 05Governance drift
- 06Redirect & migration planning
- 07Brittle integrations & plugin load
- 08Absent staff publishing model
- 09Unclear approvals
- 10Analytics without operational use
- 11Overbuilt custom substitutes
- 12Timeline vs. content reality
Operational risk assessment
Risk review framework
Tap any heading for the signals we listen for plus the 0–3 score cue. Intended for skim on a phone, detail on demand in the room.
First item stays open below as orientation—collapse when you're pacing through live.
01Audience pathway clarity
Navigation and hierarchies drift as audiences accumulate; differentiation breaks down quietly.
- ·Multiple audiences funnel through identical primary paths.
- ·Staff route users verbally rather than fixing navigation.
- ·Seven-plus top-level items without a stable hierarchy.
02Donation, member & service journey clarity
Primary journeys are treated as discrete pages rather than coherent paths with measurable drop-off.
- ·No conversion goals or benchmarks for flagship actions.
- ·Thank-you confirmation scope excluded from UX plan.
- ·Mobile flows launched without stakeholder testing.
03CMS dependence on developers
Routine publishing routed through engineers becomes backlog governance alone cannot dissolve.
- ·Critical pages require vendor or developer tickets.
- ·Training absent from contracted scope.
- ·Updates queue faster than approvals resolve.
04Accessibility debt
Launch audits without authoring guardrails regress with every unmanaged content patch.
- ·WCAG conformance level undocumented.
- ·No named ongoing accessibility owner.
- ·CMS allows heading skips and weak media workflows.
05Governance drift
Without calendars, ownership maps, or approval paths, inconsistency emerges within months.
- ·Publishing authority unclear between departments.
- ·Admin proliferation without decision policy.
- ·Major sections stagnant ≥60 days without explanation.
06Redirect & migration planning
URL restructuring minus redirect discipline erodes inbound equity and constituent trust.
- ·No crawl-derived redirect inventory referenced in contract.
- ·Consolidations not mapped against indexed URLs.
- ·404 monitoring omitted from continuity plan.
07Brittle integrations & plugin load
Undocumented integrations and stacks turn routine updates into breakage roulette.
- ·Active integration count undocumented.
- ·Upgrades postponed for fear of unexplained breakage.
- ·Glue code authored without failover documentation.
08Absent staff publishing model
Real workload caps rarely match abstract CMS capability — abandonment follows.
- ·No role explicitly accountable for sustained publishing.
- ·Single-person dependency without documented backup.
- ·Program leadership cannot predict realistic publish cadence.
09Unclear approvals
Ambiguous veto authority stalls publishing—or invites unsupervised shortcuts.
- ·Leadership sign-off ambiguous for modest edits.
- ·Parallel informal vetoes collide.
- ·Retainers silent on escalation when approval deadlock hits.
10Analytics without operational use
Telemetry divorced from stewardship routines produces optics, not corrective action.
- ·Dashboards absent from stewardship meetings.
- ·Flagship funnel metrics unknown at leadership altitude.
- ·Traffic summaries substitute for behavioural insight.
11Overbuilt custom substitutes
Stable SaaS primitives replaced bespoke amplify fragility without proportional payoff.
- ·Custom scope duplicates mature third-party equivalents.
- ·Replacement rationale undocumented beyond aesthetics.
- ·Post-handoff support burden underestimated.
12Timeline vs. content reality
Optimistic schedules compress migration QA and remediation into post-launch debt.
- ·Launch locked before substantive content readiness audit.
- ·Dedicated migration runway absent vendor work plan.
- ·Zero buffer sprint for remediation bursts.
Institutional scoring
Operational scoring framework
Each reviewed area earns 0–3. Twelve areas produce totals from 0 to 36. These bands summarise what sequencing usually makes sense before capital votes.
0–12
High operational risk
Stabilize governance and migration readiness before reallocating redesign capital.
13–24
Structural cleanup warranted
Treat redesign contingent on concurrent operational correction workstreams.
25–32
Redesign likely appropriate
Foundations workable — refreshed IA/visual systems may be the smartest lever.
33–36
Keep and refine what works
Surgical optimisation often outperforms replacement on net risk-adjusted value.
| Total score | What it suggests | Typical next sequencing |
|---|---|---|
| 0–12 | High operational risk | Stabilize governance and migration readiness before reallocating redesign capital. |
| 13–24 | Structural cleanup warranted | Treat redesign contingent on concurrent operational correction workstreams. |
| 25–32 | Redesign likely appropriate | Foundations workable — refreshed IA/visual systems may be the smartest lever. |
| 33–36 | Keep and refine what works | Surgical optimisation often outperforms replacement on net risk-adjusted value. |
Board & procurement
Procurement checklist & vendor expectations
Bring these questions into sourcing discussions unchanged if they fit — circulate the print view for packets (no signup wall).
Questions before vendor approval
- 01Who owns the site operationally after launch — and what does that ownership specifically include?
- 02What happens to existing URLs? Is redirect planning included in project scope?
- 03How will accessibility be tested, by whom, and against which standard and conformance level?
- 04Can staff edit core pages, navigation, and team listings without developer involvement?
- 05Which systems remain the authoritative source of truth for donor, member, and constituent data?
- 06What is explicitly included in content migration?
- 07What is explicitly excluded from content migration?
- 08What does post-launch support actually cover, and for what duration?
- 09What happens if the organization needs to change vendors two years after launch?
- 10Who owns content governance and publishing decisions after the vendor relationship ends?
What should be clarified before engineers start
- Sitemap documentation — current and proposed architecture, with rationale.
- Redirect planning — mapping of URL changes and destination targets.
- Governance recommendations — publishing model, approval chain, ownership structure.
- Accessibility methodology — testing approach, standard level, ongoing compliance.
- Migration planning — content, integrations, and domain authority preservation.
- CMS ownership documentation — independent operational use after handoff.
- Analytics strategy — what is measured, how it is configured, who owns it.
- Workflow documentation — how staff publish and maintain the site.
- Operational handoff planning — training, documentation, post-launch support scope.
Leaving these artefacts undefined until sprint work begins predictably concentrates risk — materially.
Request a 20-minute
website risk review
A short operational review focused on governance, accessibility, migration risk, publishing structure, and long-term maintainability.
Request reviewFor nonprofits, associations, public agencies & civic institutions. Founder-led. No obligation.