Static site or CMS? The question I get asked most

This question comes up in nearly every web project I consult on, and it's almost never actually about static versus dynamic technology — it's about who needs to change the content, how often, and whether they're comfortable with a text editor or need a visual interface. Get that question right and the technical answer mostly falls out on its own.

The question people actually mean to ask

"Static or CMS" sounds like a technology question, but the technology rarely determines the right outcome. A static site built with a generator like Eleventy or Astro can be just as visually polished as anything built on WordPress. A CMS-backed site can be just as fast, with the right caching layer. The real questions are about workflow: who edits, how often, and what happens if that person can't write Markdown or isn't comfortable with a git-based workflow.

Who edits content, and how often

If the people updating the site are developers, or comfortable with version control, a static site generator removes an entire category of CMS maintenance — no database to back up, no admin panel to secure, no plugin ecosystem to keep patched. Content lives in files, changes go through the same review process as code, and deploys are simple.

If the people updating the site are not developers — marketing staff, a small business owner, anyone who needs a visual editing experience — a CMS with a proper editorial interface is usually the right call regardless of the performance or security tradeoffs, because a site that the actual content owners can't maintain becomes stale within months no matter how technically sound it is.

When you actually need dynamic behavior

Some sites need server-side logic that static generation genuinely can't provide on its own: user accounts, real-time data, personalized content, e-commerce checkout flows, anything requiring a database query per request. For these, the static-versus-CMS framing doesn't apply cleanly — you need either a CMS, a headless CMS paired with a static frontend, or a custom application.

A hybrid that's worked well for several clients: a static-generated marketing site for everything that doesn't change often, paired with a small dynamic application (often containerized, tying back to the Docker posts on this site) for the parts that genuinely need server-side logic, like a contact form backend or a customer portal.

The maintenance burden nobody mentions

The conversation about CMS platforms often focuses on initial setup cost and underweights ongoing maintenance. A WordPress install needs core updates, plugin updates, and a hosting environment patched against an ecosystem that's a frequent target precisely because it's so widely deployed. None of that is necessarily a dealbreaker — it's a known, manageable cost — but it's a cost that a static site simply doesn't carry, since there's no admin panel, no plugin layer, and no database to be a target in the first place.

For a client without dedicated technical staff, this maintenance burden is often the deciding factor, more than any performance benchmark.

The rule I actually use

When a client asks, this is roughly the decision tree I walk through with them:

• If non-technical staff need to edit content regularly and want a visual interface → CMS, ideally one with a good track record for security updates.
• If the team is comfortable with Markdown and git, or updates are infrequent and can go through a developer → static site generator.
• If there's a genuine need for user accounts, real-time data, or e-commerce → a proper application, possibly with a static marketing layer in front of it.
• If unsure → start static. It's almost always easier to add a CMS or dynamic backend later than to migrate away from a CMS that's grown more complex than the site actually needs.

None of this is a strong opinion about technology — it's a strong opinion about matching the tool to who actually has to live with it after launch.