Does a business website need a CMS?
A content management system is an answer to the question “how does someone with no technical knowledge change a piece of text”. If that question does not arise in your company, a CMS solves a problem you do not have — and brings its own.
In short
- The decisive question is not "which system" but "who changes what, how often".
- A classic CMS pays off when several people with no technical knowledge change content regularly.
- Generated static pages are faster, safer and cheaper to run — but require someone who can handle files.
- The largest hidden item in a CMS is maintenance: updates, extensions, security fixes.
The four questions
1. Who changes content?
One person with a technical grounding, or several without? That is the most important question — a CMS exists precisely for the second case.
2. How often?
Several times a week, monthly, or twice a year? With infrequent changes the running cost of a CMS exceeds the benefit.
3. How many pages, and how similar?
Twelve individual pages or 200 built from templates? With many similar pages — language versions, for instance — generating from data is the clear winner, whatever the system.
4. Do you need functions beyond text?
A shop, a login area, booking, customer accounts? Then there is hardly a way around a system with a database.
The three routes
| Classic CMS | Generated static pages | Site builder | |
|---|---|---|---|
| Editing by non-technical staff | yes | limited | yes |
| Load time | medium to slow | very fast | medium |
| Maintenance effort | high, ongoing | very low | none |
| Attack surface | large | minimal | with the provider |
| Running cost | medium | very low | medium to high |
| Many language versions | with an extension | very good | usually weak |
| Getting out | laborious | trivial – files | often difficult |
| Shop, login | yes | only with a separate service | depends on provider |
Worth knowing
The largest cost block in a classic CMS is not the setup but the maintenance: updates to the core and to extensions, security checks, occasional compatibility problems after an update.
Two to six hours per quarter is realistic for that — permanently, without a single piece of content getting better. Fail to plan that time and after two years you are running a website with known security holes. That item is missing from nearly every quote comparison.
How generated static pages work
The approach is simpler than the name suggests: content sits in text files, a program assembles it with templates into finished HTML pages, and the server only delivers finished files.
The properties in the table follow from that:
- Fast, because nothing is computed on each request.
- Safe, because there is no database and no login area to attack.
- Cheap, because serving static files needs almost no server capacity.
- Good for many languages, because the same template is generated with different text files.
The price: anyone wanting to make a change works with files and triggers a build. For a person with a technical grounding that is a matter of minutes — for someone without, it is a barrier.
The most common wrong decision is an extensive CMS for a website that gets changed twice a year. It gets set up, fitted with extensions, and after that nobody attends to updates — because nobody has the website in view when it does not change.
After two years an outdated installation is sitting on the internet, often with known vulnerabilities. For rarely changed websites, freedom from maintenance is the strongest argument for the static route — stronger than load time and cost combined.
The decision in brief
| If … | … then |
|---|---|
| several non-technical people change things regularly | classic CMS |
| one person with a grounding maintains it, many languages | generated static pages |
| changes are rare, no staff for maintenance | generated static pages or a site builder |
| a shop, login or booking is needed | CMS or a dedicated application |
| something has to exist quickly, no budget | site builder – with an eye on getting out |
Help me decide which kind of website technology suits us. Our situation: - Who changes content: [number of people, technical background] - How often changes happen: [details] - Number of pages today: [number] - Languages: [list] - Do we need a shop, a login area or booking? [yes/no, what] - Who looks after maintenance and updates: [person or "nobody"] - Budget for setup and running costs: [amounts] Tasks: 1. Answer the four decision questions for our case: who changes, how often, how many and how similar the pages, which functions beyond text. 2. Recommend one of the three routes – classic CMS, generated static pages, site builder – and justify it. 3. Project the maintenance effort for the recommended variant over three years, including our own working time. If nobody is responsible for maintenance, say clearly what that means for the recommendation. 4. Name what a later move away from this variant would involve. 5. Name the two points where our details are insufficient for a confident recommendation. Do not recommend specific products.
In closing
A CMS is not a default but a solution to a particular case: several people with no technical knowledge changing content regularly. If that does not apply, you are paying maintenance and attack surface for a benefit that never arises.
For small companies with one maintaining person, many language versions and no shop, generated static pages are nearly always the cheaper choice — above all because they require no maintenance at all.
Common questions
Does every business website need a CMS?
No. A content management system solves the question of how several people with no technical knowledge change content regularly. If that question does not arise — because one person with a grounding maintains it, or changes are rare — it mainly brings maintenance effort and attack surface.
What are generated static pages?
Content sits in text files, a program assembles it with templates into finished HTML pages, and the server only delivers files. That is fast, because nothing is computed on request; safe, because there is no database; cheap to run; and particularly well suited to many language versions.
What does a CMS cost to run?
The largest item is not the setup but the maintenance: updates to core and extensions, security checks, occasional problems after updates. Two to six hours per quarter is realistic, permanently — an item missing from nearly every quote comparison.
When is a site builder worth it?
When something has to exist quickly, there is no budget for setup, and nobody can take on maintenance. What has to be checked first is the exit: whether text, images and address structure can be exported in full — otherwise a later switch means rebuilding rather than moving.
What speaks for which solution with many languages?
Generated static pages, because the same template gets built with different text files and every change to the template automatically reaches all languages. Classic systems need extensions for that; site builders are usually weak with many language versions.
Marketing that sets itself up
The Studio Engine beta is live. Claim your spot and help shape it from the start.
Join the beta →