Do You Actually Need a CMS? A Decision Guide

A CMS is infrastructure you have to maintain. Here is how to tell whether your content volume justifies it — most sites' does not.

The default assumption is that a website needs a CMS. For a marketing site with twenty pages updated a few times a year, that assumption adds a database, an admin interface, a security surface and a monthly bill in exchange for convenience nobody uses.

Skip the CMS when

• Content changes less than weekly and the people changing it are comfortable with a simple editing flow.
• The content is highly structured and benefits from being versioned alongside the code — pricing, service definitions, case studies.
• You want the fastest possible site with no runtime dependency on a third-party API.

In that case, content as typed files in the repository is genuinely better: every change is reviewable, reversible and deployed atomically with the code that renders it. This blog works exactly that way.

You need a CMS when

• Non-technical people publish frequently and independently, and waiting for a developer would throttle the business.
• Multiple contributors need drafts, scheduling, and an approval workflow.
• Content is reused across channels — website, app, newsletter, marketplace — from one source.
• Volume is large enough that finding and editing a file becomes the bottleneck.

Choosing between them

If you do need one, weigh three things above features: the export path if you leave, the pricing model as your content grows, and whether editors can preview exactly what they will publish. Feature comparison tables rarely predict satisfaction; those three do.

• weekly the publishing frequency where a CMS starts paying
• 0 runtime dependencies with file-based content
• 3 criteria that matter more than feature lists