We wrote four posts about when you don't need a content system. It would be convenient to stop there. But we live off simple websites ourselves, so we owe you the part our own camp leaves out.
The most famous defector came back
Joost de Valk, Yoast's founder, left WordPress and moved his blog to a static generator. Everyone wrote about it, us included. What got written about less: a while later, he moved again. To a content system.
His critic added a number worth knowing: a static blog, left alone for a year, accumulated 22 outdated packages, including ones where updating breaks the code. Dependency hell doesn't disappear. It just moves.
That leaves an important distinction both sides usually skip. A hand-written page with no dependencies (plain HTML, CSS, and a bit of JavaScript) really is long-lived: it'll still work in ten years with nobody touching it. A page built on a modern framework just carries a different maintenance bill than WordPress, not none. "Static" isn't one thing. When we say we build simply, we mean the first kind.
The question isn't about code, it's about keys
Rick Hurst, whose two-question test we quoted earlier, asks a third question that nobody in the "just hard code it" camp asks: who will maintain the site, and do they understand the hosting setup well enough not to leak secret keys?
A static page removes the database. But it adds deployment keys, API keys, and environment settings, now formally the owner's responsibility instead of a developer's. A content system hides that surface behind a login screen. That's a real transfer of risk, and it doesn't show up in any speed comparison.
Our own answer to this is simple: we hold the keys, the owner gets the website and our phone number. But if you're building it yourself, ask this question before launch, not after the first incident.
Cheap rebuilds make content migration expensive
Here's a mechanism we didn't expect. DatoCMS's author rewrote his own site onto new framework after new framework, and eventually gave up: he moved the content into a content system so he could change only the template, not the text itself.
The logic runs backwards from how it looks. AI makes rebuilding cheaper. So you rebuild more often. So content trapped in the page's code gets dragged through every migration by hand. The pain arrives the third time, never during the demo that talked you into it.
What to do about it without a CMS: keep content separate from the template from day one, even on the simplest page. Text in one file, layout in another. It takes an hour and saves a week, two years from now.
A prompt is a worse editor than a button, if you're not the one editing
Telling an AI "change the opening hours" is a great interface for the person who built the site. And a poor one for whoever just inherited it. A Webflow specialist, who uses AI himself, notes that the prompt approach is "far from ideal for clients who aren't technically savvy," because a visual editor gives immediate feedback and a text prompt doesn't. You only see the result after the AI has already done something.
That's a fair limit on "just ask the AI." Great for the builder, mediocre for the owner. Solving exactly that flip is what a content system was invented for.
An industry has appeared to fix it
A market signal you can't ignore: services already exist that rescue failed AI-generated projects. One writer summed it up: "When an entire industry emerges to fix your approach, your approach has a problem."
A concrete example: a designer tried replacing a Webflow site with one generated by Claude Code. Within days, Google Search Console started showing errors, then came the loop nobody warns you about: fix one problem, another appears. He kept the generated site, but plans a move to Webflow as the project grows. A separate study (Veracode, 2025) found AI-generated code has security vulnerabilities 45 percent of the time.
Both things are true at once: a simple AI-generated site can be excellent, and an AI-generated site can break in ways the owner never sees. The difference is a person reviewing what the AI did. That's why we're not "AI generates it, we forward it along." We're the people who review it.
And one more thing, about the fun of it
Hurst, who once built his own systems too, warns about a trap that isn't bad code. It's fun. Building your own system is "fun as a learning exercise," and that exact fun is what drives an entire industry to rebuild the same layer from scratch every decade. AI made that fun even cheaper. If you're building a site for a business, not for yourself, it's worth keeping in mind.
A conclusion, with conditions
The same conclusion as the four posts before this one, only now with the conditions it would be dishonest to leave out. A simple page wins when it's genuinely simple (no frameworks, no dependencies), when the keys are held by someone who understands them, when content is separated from layout from day one, and when someone reviews what the AI did.
Everything else isn't a question of ideology. It's a question of roles and maintenance. That question can be settled in a single conversation, and it's free.