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 and hand them over, so the handover question is part of my job rather than an afterthought. Your first action is one sentence: write down the name of the person who will edit the site next month.
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. Consider a volunteer secretary who already handles registrations and hall bookings: they are unlikely 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. Picture a visitor landing on a Saturday in March and reading a tournament poster from last November. They do 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. It also found that 46% did not receive a fix from the developer in time for public disclosure. This suggests the exposure sits mostly in the plugin layer, which is the layer a volunteer-run site is most likely to accumulate and least likely to review.
The floor moves too. The WordPress core team announced that WordPress 7.0 drops PHP 7.2 and 7.3, making 7.4 the minimum supported version and 8.3 the recommended one. WordPress has since moved on to 7.1.2, released on 22 September 2026 according to the WordPress news feed. 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 that recommends using different URLs for each language version rather than cookies or browser settings. 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, and the multilingual side of static builds is unpacked in five-language Next.js content parity.
Do you need a CMS for your website, or is a static site enough?
Most small organizations do not need a CMS, and you can settle the static website vs CMS question 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. This threshold is my rule of thumb, not a published standard.
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 does a CMS earn its keep?
A CMS earns its keep when editorial volume, several authors, approval steps or a filterable archive are real requirements, because static delivery has a real cost too.
The honest objection 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.
"Bottleneck" overstates it, though. 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.
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. The headless CMS glossary entry and the best CMS options for marketing sites list help once you know you need one.
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 each option cost after handover?
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. A four-page bilingual site like the Dubica build fits inside those limits with room to spare, though you should check current limits before relying on them. 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. A Jamstack-style static setup is the usual name for the first path.
What does a visitor see after handover?
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.
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 probably 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?