How to Build a Nonprofit Website Your Team Can Actually Maintain
Key takeaways
- A website the Communications team cannot update independently decays by design, because every change that requires a developer becomes a delay, a cost and a small institutional failure.
- Maintainability is a design requirement that must appear in the brief, the evaluation criteria and acceptance testing, or the agency will optimise for visual quality and on-time delivery instead.
- A maintainable CMS lets a non-technical staff member work confidently after roughly a half-day of training, using structured content fields rather than a single freeform rich-text area.
- A component library of pre-designed, accessible blocks lets staff assemble new campaign, event and programme pages without developer help, so the site grows with the organisation.
- Documentation should capture how to publish content, update navigation and manage images so institutional knowledge survives staff turnover rather than living in one person's head.
- Before accepting delivery, have a non-technical staff member perform routine tasks unaided — publish a post, update a programme page, add a team member, upload a report, change a footer detail and build a simple landing page.
Summary
A website that the Communications team cannot maintain independently is infrastructure that decays by design. From the day of launch, every content change that requires developer involvement is a delay, a cost, and a small institutional failure. Over twelve months, these accumulate into a website that is materially less current, accurate, and credible than it was on launch day — not through neglect, but through the structural dependency that was built into it.Editorial independence — the ability of a non-technical Communications Director to publish new content, update governance documents, create campaign pages, and correct inaccuracies without external developer involvement — is a governance requirement, not a convenience. It determines whether the website remains an accurate, current institutional document or becomes a gradually outdated record of what the organisation was when the site was built.This post covers how to specify, procure, and build a nonprofit website that a non-technical team can maintain genuinely independently: the editorial independence requirements that should be stated explicitly in the project brief, the CMS architecture decisions that determine whether the editorial team can do their job without breaking the site, the platform and framework choices that support editorial independence under real-world conditions, the editorial training that the handover process must include for independence to be genuine rather than nominal, and the ongoing monitoring that verifies independence is being maintained. The post also covers what the organisation should expect when independence breaks down and how to contract for that scenario in a way that does not recreate the dependency the original build was designed to eliminate.
There is a version of this conversation that happens in every organisation, six to eighteen months after a website launch. The new site looked great. The agency was professional. The training session covered the basics. But now the comms coordinator has left, the person who attended the training has forgotten the CMS, nobody can find the login for the hosting panel, and the website that cost £30,000 to build is deteriorating for lack of anyone who knows how to update it.
This outcome is not bad luck. It's bad specification. The brief didn't include maintainability as a requirement — so the agency didn't build for it.
Maintainability Is a Design Requirement, Not an Afterthought
When you specify a website project, the question "can our team maintain this without specialist help?" should appear in the brief, the evaluation criteria, and the acceptance testing. If it doesn't, the agency will optimise for what they're measured on — typically visual quality, technical performance, and on-time delivery — not for the day-to-day reality of your communications team trying to update a programme page eight months after launch.
What "Maintainable" Actually Means
CMS That Matches Team Capability
A CMS is maintainable if a non-technical staff member can use it confidently after a half-day of training. Not a developer. Not someone with digital as their specialist background. A communications coordinator or an operations assistant. If the system requires technical knowledge to operate safely, it is not appropriate for a nonprofit team without dedicated technical staff.
Structured Content, Not Freeform Rich Text
The most maintainable content architecture uses structured fields — separate inputs for headline, body copy, image, and call to action — rather than a single rich text area where everything is formatted manually. Structured fields enforce consistency and reduce the risk of formatting errors that require developer intervention to fix.
Component-Based Page Building
If new pages require a developer to create, your team will stop creating them. A component library — pre-designed, accessible blocks that staff can assemble into any page configuration — means campaign pages, event pages, and programme updates can be published without technical help. This is the difference between a website that grows with the organisation and one that calculates its budget every time it needs a new page.
Documentation That Survives Staff Turnover
Institutional knowledge about how to use the website should live in written documentation, not in the heads of whoever attended the training session. This includes: how to publish different content types, how to update the navigation, where images are stored and what specifications they need to meet, how forms are configured, and who to contact for different types of issues.
Questions to Ask During Agency Selection
| Question | Good Answer | Red Flag |
|---|---|---|
| How will our team update the site after launch? | Describes CMS, training, and documentation | "We provide ongoing support packages" |
| Can we see a demo of the CMS? | Yes, immediately | Deflection or "we'll cover that in onboarding" |
| What happens if we need a new page type? | Staff can build from component library | "We'd create a template for you" |
| What training do you provide? | Recorded video, written guide, live session | "A handover call at the end of the project" |
| What does a typical month of maintenance look like? | Honest account with specific task types | Vague or assumes ongoing agency involvement |
| Who owns the site if we part ways? | Organisation owns all assets from day one | Unclear or deferred to contract discussion |
The Six-Month Maintainability Test
Before accepting delivery of any website project, ask the agency to demonstrate that a non-technical staff member can perform the following tasks without assistance: publish a new blog post, update a programme page, add a team member to the staff listing, upload a new annual report, change a phone number in the footer, and create a simple landing page for an event.
If any of these tasks require developer involvement, they are not yet complete requirements — regardless of what the project specification said.
Further Reading
- The Real Cost of Developer Dependency in Nonprofit Websites
- NGO Websites Are Governance Problems Not Design Problems
- Website Governance During Nonprofit Leadership Transitions
- Nonprofit Website Design: Governance Before Aesthetics
What Team Independence Actually Changes
Comms teams at organisations with maintainable websites describe the same shift: the website stops being a bottleneck and becomes a tool they control. A campaign page that would have taken two weeks to brief, develop, and launch now takes an afternoon. A programme update that would have sat in a developer's queue for ten days gets published the same day the information changes. Staff onboarding includes the CMS as a standard tool, not a specialist system that only one person knows how to use.
The website still requires investment and attention. But the nature of the investment changes — from reactive firefighting and developer dependency to deliberate, planned content work that the team actually has capacity to do.
Frequently asked questions
A maintainable website has four characteristics: a CMS that allows non-technical staff to perform all routine content tasks without developer assistance, structured content fields that prevent layout-breaking mistakes, comprehensive documentation that enables any trained team member to manage the site, and a platform with stable hosting that doesn't require regular technical maintenance. Most nonprofit websites fail on at least one of these — typically because they were built for launch rather than for long-term maintainability.
The key CMS features for non-technical accessibility are: visual editing (content is edited in context rather than in code), structured content fields (text fields, image fields, date fields rather than a single rich text block), reference fields for relating content items without code, a clear media library for image management, and a publishing workflow that allows draft review before going live. Platforms like Webflow provide most of these natively; many WordPress configurations require additional plugins to achieve the same result.
At minimum, three people at different seniority levels should have CMS access and training: a primary content manager (typically the communications coordinator), a secondary who can cover absences (typically the communications director or a senior programme staff member), and an administrator with full access for governance changes (typically the communications director or an operations lead). Single-person CMS dependency is almost as risky as full developer dependency — illness, resignation, or leave creates the same access gap.
Internal teams should be able to: create and edit all page content, upload and manage images with basic optimisation, create new blog posts and programme pages, adjust navigation if the CMS allows it, manage forms and update form destinations, publish and schedule content, manage CMS collection items (staff profiles, programme listings, news items), and access analytics. Any task on this list that currently requires developer support is a maintainability failure that should be addressed either through platform choice or training.
Structural safeguards are more reliable than editorial discipline. Structured CMS fields — separate fields for heading, body text, and images rather than a single rich text block — prevent layout-breaking content errors. Component-based page building prevents inconsistent formatting. Image fields with defined aspect ratios prevent distorted layouts. Style guides and editorial guidelines document the standards that structure enforces. The goal is a CMS that makes the right content format the path of least resistance, so that mistakes require deliberate effort rather than careless action.
The documentation package should include: a CMS user guide covering every routine task with screenshots, a content governance document specifying who can publish what and what approval is required, a style guide covering writing standards, image standards, and formatting conventions, a vendor contact list for escalating technical issues, a credential register, and a troubleshooting guide for common issues. This documentation should be reviewed and updated every time the platform or governance framework changes.
For an active nonprofit website with regular content publishing, budget 5-8 hours per week for a part-time content manager role: 2-3 hours for new content (blog posts, programme updates, news), 1-2 hours for content maintenance (reviewing accuracy, updating outdated information), 1-2 hours for analytics review and content performance assessment, and 1 hour for monitoring and miscellaneous tasks. This assumes a purpose-built platform; dependency-heavy platforms can triple this estimate.
Management is the day-to-day activity of publishing content and keeping information current. Maintenance is the longer-term activity of keeping the platform stable, the design system consistent, the compliance current, and the governance framework up to date. A team can manage a site without being able to maintain it — they can publish content without being able to address structural drift, design inconsistency, or compliance deterioration. Both capabilities are needed; most teams are trained in management and untrained in maintenance.
The safeguard against staff turnover is documentation comprehensive enough to enable a new team member to manage the site independently within their first two weeks. This requires: written process guides for every routine task, a CMS that is self-explanatory enough to supplement the guides, documented governance frameworks that explain not just how to do things but why, and a structured onboarding process for new staff that includes website management training. Organisations that rely on institutional knowledge rather than documentation lose capability every time a staff member leaves.
Platform features that indicate genuine maintainability: a visual CMS where changes are previewed before publishing, role-based access control so different team members have appropriate permissions, a revision history that allows mistakes to be reversed, a staging or draft environment for reviewing changes before they go live, clear error messages when content requirements aren't met, and a stable hosting environment that doesn't require regular technical intervention. Webflow's native CMS provides most of these; achieving them on WordPress typically requires multiple plugins.
