What Is Your CMS Actually Costing You?

Every website conversation starts by choosing a content management system. Which one, which host for it, which theme, which plugins. Nobody asks the question underneath all of that, which is whether this particular website needs a content management system at all.

First, in case the term is doing more work than it should. A content management system, or CMS, is the software your website runs on. WordPress is one. So are Squarespace, Wix, Shopify, and Drupal. If you log into your website to change a phone number or add a page, you’re using one.

Underneath, they’re built the same way: your content lives in a database, a theme decides how it looks, and every page gets assembled fresh each time somebody asks for it. Squarespace hides most of that machinery from you and WordPress hands you the keys to it, which is a real difference in how they feel to use. It’s a difference in how much you’re allowed to touch. The architecture underneath is the same one, and that shared architecture is what this post is about.

I also want to be upfront that this sounds like a person who builds static websites inventing a reason you need static websites. That’s a fair suspicion and I’d have it too.

So here’s the disclosure. I build sites this way, I’ve moved every site I personally care about off WordPress, and I’d obviously be happy to do the same for you. Read the rest with that in mind. What I’d ask is that you notice I’m not proposing you switch to a different CMS. I’m proposing you might not need the category, which is a strange thing to sell, because there’s nothing to lock you into afterward.

The CMS Solved a Real Problem

This part gets skipped in most arguments like this one, and skipping it makes the argument worse.

In 2005, if you wanted to change a sentence on your website, you edited an HTML file and uploaded it over FTP. If you had a hundred pages and wanted to change the navigation, you edited a hundred files. If you wanted a colleague to publish something, they needed the FTP password and enough knowledge not to destroy anything. There was no version history. If you overwrote something, it was gone.

WordPress and its contemporaries fixed all of that, and it was a genuine liberation. One place to log in. Templates so the navigation lived in one file instead of a hundred. Non-technical people publishing without touching code. Revisions. Multiple authors with different permissions. It deserved to win, and it won for good reasons.

Every one of those problems was caused by a constraint that no longer exists.

What Changed

Templates and shared layouts aren’t a CMS feature anymore, they’re just how site building works. Version history came from Git, which is better at it than any CMS revision system. Deployment is automatic: change the content, the site rebuilds and publishes itself in under a minute, with no FTP anywhere. Content lives in plain text files that are readable, portable, and impossible to trap in a proprietary database.

And the thing that actually took the longest to arrive: editing interfaces that write to those files. You can have an admin panel, log into it, edit your content in something that looks like a normal editor, hit save, and have it commit a text file and rebuild the site. No database involved anywhere.

We adopted content management systems to solve problems that the tooling underneath them eventually solved on its own.

The CMS stayed anyway, because that’s what happens. Nobody re-examines a decision that isn’t visibly failing.

What the Machinery Costs

Here’s what you’re still carrying to keep that CMS running.

A database. This is the big one. A database means code executing on your server on every page load, which means a login to protect, an interface exposed to the internet, and a permanent supply of places for someone to inject something. Nearly every serious website compromise routes through this. WordPress didn’t invent the problem. Any system that assembles pages on demand instead of serving files that already exist carries the same cost.

Plugins. The reason WordPress can do anything is that thousands of people have written extensions for it. The consequence is that your site’s security is the security of the least careful of those authors, and you have no practical way to evaluate that. Every plugin is a door, installed by you, maintained by a stranger.

Performance you fight forever. A CMS builds each page when it’s requested, so you add caching to stop it from doing that, then you add a CDN, then you tune the caching because it broke something. Sites I’ve rebuilt as static files have gone from Lighthouse scores in the 40s to the high 90s with the same content, the same copy, the same images. Not because I’m clever. Because the work of assembling the page moved to before the visitor arrived instead of during.

The template you’re actually inside of. This is the one people notice last. Your site looks the way it does because someone picked a theme, and everything you want from then on gets evaluated against whether the theme supports it. The answer is often “not without a plugin” or “not really.” You end up designing around software constraints instead of around your business, and it’s so gradual that it never feels like a decision.

The Middle Path, Since It Should Be Said

The choice isn’t between a full CMS and editing code.

Git-based content editors, Keystatic and similar tools, give you an admin interface that looks and works like a normal CMS. You log in, you edit, you publish. What’s different is where it writes: to text files in your repository, not to a database. The site rebuilds and deploys itself.

You get the editing experience. You don’t get the database, the login exposed to the internet, the plugin ecosystem, or the attack surface. For most business sites this is genuinely the sweet spot, and I mention it because leaving it out would let me pretend the choice is more dramatic than it is.

It isn’t risk-free either, to be fair. Your content lives in a repository on a platform you don’t own, and accounts get compromised. What changes is that the exposure moves to a system with real security engineering behind it, instead of sitting on your $12/month shared host being probed a thousand times a day.

The Content Update Question

Here’s where I think people expect me to say “and I’ll handle your updates,” and where I want to be careful, because that’s a fair thing to be suspicious of. Trading a maintenance vendor for a different maintenance vendor isn’t much of an offer.

So look at the actual math rather than the pitch.

Most content changes on a business website take under an hour. Adding a page, updating a bio, changing pricing, publishing a post. Two hours if it’s involved. Now ask how often you genuinely change anything. For most businesses the honest answer is somewhere between four and twenty times a year.

That’s the comparison. A handful of hours annually, billed when work actually happens, against $3,600 a year charged whether anyone touched the site or not. Plus free hosting, because static files cost nothing to serve at this scale.

And there’s an assumption worth examining in “but I want to edit it myself.” Many of the people paying a monthly fee already can’t edit their site, or won’t, or tried once and it broke. If you’re paying someone every month and still emailing them to change a phone number, you’re not buying self-sufficiency. You’re paying a subscription for the thing you’d otherwise pay for by the hour.

If you do want to edit it yourself, use the git-based editor and edit it yourself. Both options are available. What you don’t have to do is buy the database to get either one.

Going Backward on Purpose

There’s a version of this argument that’s just nostalgia, and I want to avoid it. Static HTML in 2005 was miserable. I’m not proposing we return to it and I wouldn’t want to.

What’s happened is that the reasons we left have been solved by better tooling, and we can now have the good part of that era, which was that a website was a set of files and files are simple, without the bad part, which was that maintaining them by hand was unbearable. The build step does the tedious work. You get the simplicity without the labor.

The workaround outlived the problem it solved. Retiring it is just housekeeping.

The recurring costs of that machinery are itemized in the true cost of running WordPress, and the performance side is in why your WordPress site is slow. If you want to check what your current arrangement is actually delivering, there’s a short audit in what is your website maintenance actually buying you.