A demonstration · August 2026 · 6 min read

Will the CMS die?

This website publishes in eleven languages with no CMS and no database. The whole thing is flat text, git and one human at the gate saying deploy. We reviewed our own publishing setup honestly, and the verdict is at the end. AI eats the CMS. It does not eat the gate.

Los ensayos se publican en inglés.

TL;DR

krds.ai runs with no CMS and no database. Agents write plain files into git, a script verifies all 264 pages, a human reviews the staging build and says deploy. A CMS makes you run an app server and a managed database, the most expensive line on a cloud bill, to store text that gets prerendered anyway. Git beats CMS versioning outright. What survives is the gate: UAT for content, a verified build and an accountable human. No CMS. Still a gate.

This website has no CMS. No admin panel, no content database, no plugin marketplace, no vendor invoice. Eleven languages, two hundred and sixty-four pages, seventeen essays, published and updated every week. We did not sit down one day and decide to make a statement about the CMS industry. We just built the site, kept publishing, and noticed months later that the thing everyone says you cannot publish without was simply not there. It felt like noticing you have stopped wearing a watch.

Here is what a CMS actually signs you up for. An application server that has to stay up all night. A database behind it, and anyone who has seen an AWS or Azure bill knows the managed database is the most expensive line on it. An admin panel that needs patching, plugins that need updating, backups that need testing on a Sunday. All of this machinery to store text. And here is the funny part. If you care about speed and search, that text gets prerendered into static pages anyway. The database sits there, expensive and attackable, guarding words that were always going to end up as flat HTML. Our whole site is flat pages served by nginx. If your content is text, and most content is text, flat pages win on cost, on speed, and on the number of doors a hacker can knock on.

How publishing works here

We tell an agent what the essay should say and how the argument should run. The agent writes it into plain files in a git repository and rebuilds the site. A script then checks all two hundred and sixty-four pages for broken labels, missing translations and dead routes. Then one of us sits down and reads a local build of the site, the same pages that will go live, on the same laptop this sentence was typed on. The industry has a name for this, UAT on staging. Our version of it is a man reading his own website with his morning coffee. When the words are right he says one word. Deploy. Three minutes later the essay is live in eleven languages, and if he regrets it, rolling back is one git tag.

The rollback bit deserves a pause, because versioning is one of the CMS industry's favourite things to sell. Revisions, snapshots, backup schedules, point-in-time restore. Git had all of it first and does all of it better. Every change we have ever made is diffed, timestamped and signed. Any past version of the entire site comes back with one command. There is no backup job to test because the repository is the backup, and a copy of it sits on every machine that ever touched it. Git was always the better content store. The industry kept editors away from it because the interface was hostile, not because the tool was wrong. Well, the interface is now a conversation.

The CMS was never the product. It was scaffolding around a shortage of hands, and the shortage has ended.

The gate

One thing does not go away, and it is the part the CMS never really owned. The gate. Every serious engineering team has one. Code goes to staging, someone accountable reviews it, then it goes to production. This is thirty year old discipline. Content rarely gets the same respect because the publish button made shipping feel casual, one cheerful click and the words are out there representing the company. Our gate has two layers. A script that checks every page and fails loudly when something is wrong. And a person who reads every word on the staging build and decides that these words, in this form, are ours.

The essay you are reading is proof the gate works. The first draft was turned back at the gate. Too much AI in the voice, said the human, and he struck out an entire section where the AI confidently predicted the future of CMS vendors. Show me this in my style, he said. So the agent went and read everything the human had ever written, and tried again. You are reading the third attempt. A model wrote, a human refused, the words got better. No panel involved.

That is the honest shape of what AI does to this kind of work. When producing words costs nothing, judgment becomes the whole job. The agent can write eleven locales before lunch. It cannot decide that a sentence sounds like someone else's company, or that a claim is true but should wait, because the wrong reader would meet it on the wrong morning. Somebody has to own what ships. That job was never the software's, and it is not the model's either.

The practical questions have practical answers. What about the marketing team that cannot code? They never wanted to code. They wanted to change words, and telling an agent is faster than any admin panel ever built. What about previews? The staging build is the preview, and it is not a mockup, it is the real site standing before the gate. What about the catalogue with fifty thousand products? That is a database with an API and it should stay one, product data was never the CMS's to keep. What dies is not the storing of content. It is paying rent on a panel to touch your own text through.

If you read our living website essay, this is the same story told from the other side. There the frontend stops being fixed pages and starts being composed for whoever walks in. Here the back office follows it. Writing collapses into conversation, storage collapses into git, and what is left standing on both ends is the same pair. A design system that decides what may be composed, and a gate that decides what may ship. Everything in between was scaffolding.

The verdict

So, will the CMS die? The parts that store and the parts that publish, yes, and good riddance to the invoice. The part that decides, never. The good of our setup is the cost, the speed and the ownership. The bad is that someone has to build the pipeline once, and it does need an engineer who cares. The ugly, we have looked, and we have not found it yet. And because verdicts deserve precedent, here is the oldest one on record.

My name is Ozymandias, King of Kings; Look on my Works, ye Mighty, and despair! Nothing beside remains. Round the decay of that colossal Wreck, boundless and bare, the lone and level sands stretch far away.

Percy Bysshe Shelley, Ozymandias

Shelley's traveller finds two vast and trunkless legs of stone in the desert, and near them a shattered face. The king who raised that statue ran the mightiest content platform of his age. Court sculptors, royal masons, empire-wide distribution for one man's messaging. Our industry raises its own kings. Sitecore, Sitefinity, Adobe Experience Manager, each one a king of kings in its licensing year, each one a procurement line nobody dares question. Their predecessors were once just as unquestionable. Ask Vignette.

The metaphor inside the poem is gentle. The works fell. The words did not. The inscription is the one thing the traveller carries out of the desert, and here it is on a webpage two hundred years later. Words in plain form outlast every machine built to manage them. Stone, parchment, paper, flat files.

 

Prashant Ipe · CTO, KRDS

The other half of the motion: The living website

Inicia una conversaciónInvestigación