What is a content management system (CMS) for?

A content management system is a graphical interface that lets a non-developer write to a database. The database stores content like blog posts, pages, products, and media. The CMS provides forms, buttons, and editors so a human can edit those database rows without writing SQL or code. Everything else a CMS does, including templates, page builders, plugins, workflows, and role hierarchies, is scaffolding around that one core function.

Do I still need a CMS for my website in 2026?

Most small-business websites no longer need a CMS. If the site is built from files in a git repository and the owner is comfortable using AI tools like Claude Code, the CMS becomes optional. The publishing flow is replaced by writing a prompt that the AI translates into a code change, then reviewing the diff and deploying. CMS-backed sites are still appropriate for multi-author editorial teams, large structured content libraries, compliance-bound workflows, and owners who do not want a developer-flavored stack.

How does Arrow & Bell publish blog posts without a CMS?

Blog posts live as plain TypeScript objects in a single file (app/blog/posts.ts). To publish a new post, the author writes a prompt describing the post, Claude Code edits the file to add a new entry, the change is reviewed in a git diff, and a push to the main branch triggers an automatic deploy on Cloudflare Pages. The entire publishing flow takes minutes and requires no admin panel, login, draft mode, plugin updates, or security patches.

What replaces the CMS in an AI-native stack?

In an AI-native stack, the site is files, the interface is a conversation with an AI coding tool, the deploy pipeline is git, and the human reviews code diffs instead of pushing buttons in an admin panel. Content lives directly in source files (markdown, TypeScript, JSON). The AI translates natural-language requests into code changes. Version control replaces draft and revision history. Static deployment replaces the database-and-server architecture that traditional CMSes require.

When is a CMS still the right choice?

A traditional CMS is still the right choice for multi-author editorial workflows that require permissions, audit trails, and scheduled publishing; non-technical site owners who do not want to work with a git repository or AI tools; large structured content libraries like e-commerce catalogs or real estate listings that benefit from a relational database; and compliance-bound workflows in healthcare, finance, or government where audit trails and access controls are mandatory.

What does the file structure of a site without a CMS look like?

A typical AI-native site has a content layer that is just files in folders. Blog posts live in a single TypeScript file as an array of objects. Pages are React components. AI-readable site metadata lives in plain markdown (llms.txt). Crawler rules live in plain text (robots.txt). There is no database, no separate content service, and no headless CMS sitting between the author and the deploy pipeline. The git repository is the canonical version of the entire site.

Do You Actually Need a CMS Anymore?

I haven’t logged into one in months.

Drupal, WordPress, Contentful, Sanity, Strapi, Webflow, Ghost. There is a small graveyard of admin panels I will never see again. The site you are reading does not have one. Not because we forgot, but because we no longer needed one.

This is not a manifesto. I am not going to tell you the CMS is dead. The CMS is fine and many sites still need one. I am going to tell you what changed in our stack that made it disappear, and what I think the disappearance actually means.

What was a CMS for, anyway?

A content management system is a graphical interface that lets a non-developer write to a database. That is the whole job. Everything else, the templates, the page builders, the workflows, the plugins, the role hierarchies, is scaffolding around that one core function.

A blog post lives in a row in the wp_posts table. A product lives in a row in the products table. A page lives in a row in the pages table. The database is the substrate. The CMS is the prosthetic that lets a human, with their flesh-bound consciousness and their need for buttons and forms, reach in and edit it.

Picture the elaborate diving bell that scientists used to lower into the ocean to study deep-sea life. The bell exists because the scientist cannot breathe down there. The bell is not the science. The bell is the apparatus required to keep the scientist alive while they do the science. Take away the requirement that the scientist be physically present, send a sensor down on a wire instead, and the diving bell becomes a museum piece.

The CMS is the diving bell. It exists because, until recently, the only way to get a non-developer human into the database was to build a clumsy visual contraption around it.

What replaces it

The thing that replaces the CMS is not another CMS. It is a different shape entirely.

In our setup, when I want to publish a blog post, I open Claude Code in a terminal and write something like this:

> Add a new blog post to the site. Slug should be i-havent-logged-into-a-cms-in-a-year. Title is I Haven’t Logged Into a CMS in a Year. Open with the line about the graveyard of admin panels. Build the argument that a CMS is a GUI for a database, walk through what our stack looks like instead, and end with the diving bell metaphor. About 1200 words. Then update llms.txt and add the FAQ schema entry.

Claude reads our existing posts to match the voice, edits app/blog/posts.ts to add a new entry at the top of the array, updates public/llms.txt with a one-sentence description, and adds the FAQ schema entry to app/blog/[slug]/page.tsx. Then I review the diff, ask for changes, and when it looks right, I commit and push. Cloudflare Pages auto-deploys in 90 seconds.

That is the entire publishing flow. There is no admin panel. There is no login. There is no draft mode. There is no preview environment. There is no media library, no plugin updates, no security patches, no backup schedule. Whatever I say turns into a code change, gets reviewed, gets shipped. The website is the repo and the repo is the website.

Where the database used to be

Here is what the file structure looks like for the things a CMS would normally manage:

app/
  blog/
    posts.ts          ← every blog post lives here, as a TS object
    [slug]/page.tsx   ← the template that renders any post
    page.tsx          ← the blog index page
  page.tsx            ← homepage
  about/page.tsx      ← about page
  contact/page.tsx    ← contact page
  ...
public/
  llms.txt            ← site map for AI agents, plain markdown
  robots.txt          ← crawler rules, plain text
  favicon.ico
  ...

That is the whole content layer. Posts live in a TypeScript file as a plain array of objects. Pages are React components. Site-wide AI metadata lives in plain markdown. Crawler instructions live in a text file with three sections.

There is no database. There is no separate content service. There is no headless CMS sitting between us and our deploy pipeline. The site is a folder of files, and the canonical version of every file is in our git repo.

Compare this to a traditional WordPress site. A blog post lives in a MySQL row, with metadata in a separate row, with custom fields in a third row, with a featured image stored in a media library that is itself a directory of files referenced by IDs in a fourth table. To change a post you log in, click into the post editor, navigate the gutenberg block soup, save, preview, save again, hope nothing escaped from the WYSIWYG, and pray that the four plugins you have installed do not interpret your update in unexpected ways.

That whole architecture exists because somebody, somewhere, decided non-developers needed a GUI. The GUI created the need for the database. The database created the need for the plugins. The plugins created the need for the security patches. None of it was about content. All of it was about getting a human-shaped interface in front of a database.

What this is not

I am not saying every site can ditch the CMS. There are several real cases where you cannot.

Multi-author teams with editorial workflows. If you have a newsroom with a copy desk, a fact-checker, an SEO editor, and a publisher who all need to handle a piece before it ships, you need workflow tooling. You need permissions, audit trails, scheduled publishing, version comparison. The CMS earns its keep there.

Non-technical owners with no AI workflow. If you do not know what a git repo is and do not want to learn, the CMS-shaped GUI is still the right answer. You should be using something like Webflow or Squarespace, where the diving bell is comfortable and well-lit.

Large content libraries with structured data. E-commerce catalogs with thousands of SKUs, real estate listings with rich filtering, anything that needs proper relational queries at scale. Files in a folder will not cut it.

Compliance-bound workflows. Healthcare, finance, government. The audit trail is the product. A CMS gives you that out of the box.

For everything else, which is most small-business websites, the CMS is now optional. And once you remove it, you notice how much of the daily friction in maintaining a site was actually friction with the CMS itself.

The bigger shift this points at

Content management as a category was built for one historical moment: when humans were the only thing that could write to a database, and humans needed visual interfaces to do so. Both of those constraints are weakening at the same time.

I do not think CMS goes away. I think it gets relegated to the cases above and gradually shrinks toward those use cases. Meanwhile a new category, which does not have a name yet, takes over for the rest of us. The shape of the new category is something like: your site is files, your interface is conversation, your deploy pipeline is git, and the human in the loop is reviewing diffs instead of pushing buttons.

That is not the death of content management. It is content management without the prosthetic.

I do not miss it.