A CMS is useful only when someone will actually maintain it. Every argument about platforms sits downstream of that sentence, and most platform conversations never reach it.
You have probably sat through the conversation I mean. A club, an association or a small charity decides it needs a website. Within two minutes the question is WordPress or Webflow. Within five it is themes, plugins, page builders and a hosting plan, and nobody has asked who logs in next month.
The better way to ask whether a small organization needs a CMS is to stop listing features. Ask what content genuinely changes, who changes it, and where the organization already publishes the things that change most often. Those three answers pick the platform more honestly than a feature grid does.
I build these sites. I also hand them over and then watch what happens to them afterwards, which is the part of the job that actually teaches you something.
Who logs in next month?
Name the person who will edit this website in thirty days, because a CMS with no named editor is a login nobody uses.
Say the name out loud. Not the role, not "the committee", not "whoever takes over communications in September". A person. If you cannot produce one, you have learned something about the platform decision that no comparison table will tell you.
Most small organizations cannot produce one, and that is not a failure of will. A volunteer secretary who already handles registrations and hall bookings is not going to add a weekly publishing chore, and asking them to is how websites die quietly.
When there is no named editor, the CMS still exists. It still has an admin login, a theme, a plugin set and an update queue. You have taken on the full cost of editability and collected none of the benefit.
For many local organizations, a CMS increases the chance of stale content
For many local organizations, a CMS increases the chance of stale content instead of reducing it. That reads backwards, because the entire promise of a CMS is that content becomes easy to change.
The mechanism is simple. A CMS makes updating feel cheap, so the site takes on content that needs updating. Events. "Latest news". A tournament calendar. Opening hours over the holidays. Each of those is a promise of recency, and a promise of recency turns into a liability the moment nobody is editing. A visitor landing on a Saturday in March and reading a tournament poster from last November does not conclude that the website is out of date. They conclude the club is.
A site carrying no time-sensitive content cannot fail that way. It is not more virtuous; it simply made fewer promises.
Then there is the maintenance nobody asked for. Patchstack's State of WordPress Security in 2026 recorded 11,334 new WordPress vulnerabilities during 2025, a 42% rise on the previous year, with 91% of them in plugins and only six in core. Almost half of them, 46%, had no patch available at the point of public disclosure. Core is not what that data indicts. The gallery plugin a volunteer installed in 2021 is much closer to it.
The floor moves too. WordPress 7.0, scheduled for April 2026, drops PHP 7.2 and 7.3 and raises the minimum supported version to 7.4, with 8.3 recommended. That is a sound decision for the project. For a club on shared hosting with nobody watching, it is a scheduled infrastructure chore landing in an inbox nobody reads.
What actually changes on your website?
Almost nothing changes, once you separate the content that describes the organization from the content that announces its next event.
Write the two lists. The first is who you are, what you do, where you train or meet, how to join, who to contact and what you have won. That list changes once a year, maybe twice. The second list is dates, results, cancellations and registration deadlines, and it changes constantly.
Only the second list needs a publishing workflow. And the second list is usually being published somewhere else already, because that is where the members actually are.
| Content type | Example for a local club | Where it belongs |
|---|---|---|
| Identity and history | Who the club is, when it was founded | A website page, written once |
| People and contact | Coaches, committee, phone number | A website page, edited yearly |
| Evergreen practical | How to join, where training happens | A website page |
| Time-sensitive | Tournament dates, results, cancellations | The channel members already read |
| Structured archive | Twenty years of match reports, searchable | A CMS or a database |
Only the last row of that table is a genuine argument for a CMS. The fourth row is an argument for using the organization's existing channel properly, which costs nothing and reaches the people who are already looking.
Here is how that went on Šahovski klub Dubica.
Šahovski klub Dubica needed a credible bilingual home on the web but had no maintenance contract and already posted current news on Facebook. I kept the website evergreen and sent tournament dates back to the channel the club actually uses. The result has no database, CMS account, analytics subscription or weekly publishing chore.
The build shipped as a Next.js static export with Serbian Latin at the root and English under /en/, following Google's guidance to give every language version its own URL rather than switching content behind a cookie. The production audit recorded Lighthouse 100 for accessibility, best practices and SEO, with CLS 0.00. The Šahovski klub Dubica chess club case study covers the media and accessibility work in more detail.
Does a small organization need a CMS? Score it in six questions
Most small organizations do not, and you can settle it in about ten minutes by scoring six questions instead of comparing platforms.
Score one point for each yes.
- Can you name the specific person who will edit the site next month, and have they agreed to it?
- Does the organization publish something new at least twice a month, all year round, not only in season?
- Are there two or more people who need to publish without waiting on each other?
- Does anything need review or approval before it goes live?
- Is there a structured archive readers will browse or filter, such as several hundred match reports or a member directory?
- Is there a budget line for maintenance that survives a change of committee?
Three or more points means a CMS is doing real work, and you should choose one deliberately rather than by default. Zero to two means a static site holding evergreen content, with the current material published where the members already read it.
Two of those questions carry more weight than the rest. Question one, because a platform without an editor is furniture. Question six, because maintenance is the cost that outlives everyone who voted for the website.
When a CMS earns its keep
Static delivery has a real cost, and pretending otherwise is how a developer becomes the bottleneck.
The honest objection, made for years and still true, is that a static generator puts a build step between the organization and a typo fix. A wrong phone number on a contact page should not require a developer, a commit and a deploy. If the organization needs six small text changes a year, that is fine, and it belongs in the handover conversation. If it needs six a month, you have built a bottleneck and labelled it simplicity.
Actually, "bottleneck" overstates it. You have built a dependency, and a dependency is acceptable when it is named and priced up front. What is not acceptable is discovering it eighteen months later, when the person who built the site has moved on and the committee has changed twice.
A CMS also wins outright on editorial volume and on structure. If the organization runs a real publication, has several authors, needs approval before anything goes live, or holds an archive readers will filter, those are exactly the conditions the software was built for. I have written separately about when a headless CMS does earn its place on a marketing site, and the same reasoning applies at club scale with the numbers scaled down.
If you have already decided you want a platform, the comparison worth reading first is how Webflow and WordPress differ on maintenance and ownership, followed by WordPress versus a custom-built website once you know how much of the CMS you would genuinely use.
What does the cheap option actually cost?
A static club site can run at zero hosting cost, while a managed WordPress install adds hosting, licences and either a retainer or volunteer labour.
Hosting is rarely the deciding factor on its own, but knowing the floor keeps the conversation honest. Cloudflare Pages' free plan allows 500 builds a month, 20,000 files per site and 25 MiB per individual asset, which covers a four-page bilingual club site with real photography several times over. Against that, a managed WordPress install carries hosting and plugin licences, plus either a retainer or an unpaid volunteer doing the work a retainer would pay for. The static option moves the cost forward into the build and then stops charging. The CMS option spreads it across every year the organization exists, which is the part that gets underestimated when a committee approves a website.
The handover test
Before you choose, run one test. Imagine the person who commissioned this site has left the organization, the developer is unreachable, and nobody has logged in for a year. What does a visitor see?
A static evergreen site looks the way it did on launch day. A neglected CMS looks abandoned, and by that point it is a security problem as well as an embarrassing one.
Start with the two lists
Before you talk to anyone about platforms, open a document and write the two lists from earlier: what describes your organization, and what announces its next event. Put a date beside every item in the second list showing when it last changed. Most of those dates will surprise you.
Then ask the question this entire decision rests on. Who is going to keep that second list current, and have they said yes?