Is There a Future for the CMS?
The CMS's utility overpowered its complexities for the last 20 years. Its future value is less certain.
Drupal launched in 2001, WordPress two years later. Both showed up when database-backed websites were the new, hot, thing built to solve a real, obvious problem: allowing people to publish and manage a website without needing to hand-code every page. Two decades on, CMSes still drive a huge swath of the web: together, WordPress and Drupal still run ~42 percent of the web today.1 They’re also the two CMSes we’ve used the most.
The value of the CMS
The value was real, and simple: you didn’t need to know how to code to add a page, publish a post, or swap out a photo, which empowered a wider audience to be able to update websites. As common use cases inevitably emerged, open-source communities developed a rich ecosystem of themes, modules, and plugins that provided aesthetics and functionality that further elevated these platforms and what, in many cases, came for free. Engineers were often involved in setup and maintenance, but day-to-day editing and content creation became accessible to the masses.
The cost of a database
But they always carried a cost, and it traces back to one architectural fact: a CMS keeps its content in a database, not in code. A database isn’t a file sitting in your repo; it’s a live system built to be written to, updated, and deleted at any moment, with no built-in record of what changed or when. It just serves whatever is currently there. Your application code, the HTML and JavaScript a visitor’s browser actually loads, has to reach out and connect to that database to do anything, and that connection is itself something you have to defend: a constant stream of security patches,2 an ongoing hosting bill for something that has to run a database, not just serve files. And when it goes wrong, there’s often no way back. I can still remember one painful loss of a client’s content that simply couldn’t have happened in this architecture.
Where AI tips the scale
None of this makes a CMS the wrong choice on its own. It’s a trade-off, and for a long time it was a reasonable one. A static, file-based site sidesteps everything we just described: nothing to patch, no database connection to defend, a paper trail for every change. In exchange, a database earns its place when a site is a genuinely dynamic application, one serving lots of concurrent people saving and updating things, not just publishing information outward. That’s a real distinction, and it isn’t going away until something better than a database comes along for that job.
What tips the scale now is a narrower, more practical problem: AI tools are simply better at working with code than with a database. We felt this directly on our own Drupal site. Configuration lives in different places depending on how a given feature was built, some in the database, some in template files, because Drupal is a powerful tool that can be assembled a dozen different ways. That inconsistency is exactly what trips up an AI tool: it makes building slower, less certain, harder to script, and it makes moving a change from staging to production to testing that much messier, because the same piece of content or configuration can be in more than one place at once.
A static site doesn’t have that problem. Everything, content, configuration, templates, lives in one place: files, in git. An AI tool can read the whole thing, reason about it, and make a change with far more confidence than it can against a database it has to guess its way through.
So we switched from Drupal to Astro
Our own site has made this trip twice, in opposite directions. savaslabs.com started as a static Jekyll site, and even through a 2017 redesign we chose to stick with it. By late 2019 we’d started moving to Drupal, relaunching the new brand and a rebuilt front end in early 2020. That was the right call at the time: our team, and our clients’ teams, needed non-engineers to edit without waiting on a developer, and Drupal delivered that. Now we’ve gone back to static, this time built on Astro, for the same reason this whole post has been making: the tools caught up, and the trade-off that justified the database in the first place doesn’t hold for us any longer.
Where do we go from here: chaos or commit-unity?
Most of the sites we’ve built or maintained over the years, we don’t expect them to still be running on a database-backed CMS two years from now. The advantages of a static, file-based approach are real on most axes that drive decision making: cost, complexity, and even feature richness, in the sense that matters most, everything is tracked, and it’s nearly impossible to lose anything. Add the speed of building this way, and the fact that you’re no longer coordinating a database, application code, and hosting as separate systems, and the case is strong.
None of this means you should switch platforms just because the technology changed out from under you. We expect to keep supporting clients on their current platforms for years. What we’re actually helping our partners to be thoughtful about isn’t which platform they’re on today, it’s their underlying data, and architecture, ensuring that it plays well with AI. Get that right, and whatever your front end looks like in the future, a website, app, or an entirely new framework, it will be built to work well with AI. We help our clients see where this kind of thinking can further empower their missions and visions in our AI Readiness and Opportunity Assessments.
