Do you still need a CMS when the assistant edits files?
It depends on who edits and how often. Alone, I run four sites on files in a repository and the assistant is the editor. With a team, a CMS earns its place: not every typo should have to go through an AI tool.
Margus VeeberIn short
For one person with an assistant, files in a repository do the CMS's job: every page and post is a text file, the assistant edits it, a commit is the history and a preview link is the staging site. The moment several people edit, or someone who does not write code has to fix a typo without asking an AI tool, a CMS earns its place. The question is who edits and how often, not what is technically possible.
Key takeaways
- A CMS does four jobs: a place to write, structure, permissions and publishing without code. Files in a repository cover the first two; the assistant covers the rest only for the person who uses it.
- One person with an assistant does not need a CMS. Commits are the history, preview links are the staging site, and bulk edits are one prompt.
- A team needs one the moment someone should fix a typo without an AI tool. Roles, approvals and scheduling are not free in a code stack.
- Content that leaves the site, an app or an email or a second site, wants a headless CMS with an API.
- The middle ground is real: a git-based editor on top of files, or a CMS the assistant drives through an MCP server.
- On a site built with Claude Code, Sanity or Payload are the CMSs to reach for: easy to connect, and the assistant keeps control afterwards, through Sanity's MCP server or Payload's place in the codebase.
Since I moved my sites off Webflow, the question I get most is not about the code. It is about the CMS. Four sites, no content system, every page a file, and Claude Code as the only editor. People assume that is a phase before I pick a CMS. It is not, for those sites. It would be the wrong setup for most of the teams I work with.
The short version I give on LinkedIn: when there is a team, a CMS is so much easier, because not every word change or typo has to go through an AI tool. When it is one person doing solo stuff, it is not always needed. The rest of this post is the reasoning behind that sentence.
What does a CMS actually do for you?
A content management system does four jobs: it gives you a place to write, a structure for what you write (fields like title, date, author, price), rules about who may change what, and a way to publish without touching code. Files in a repository cover the first two well. They cover the last two only through the assistant, and that is the whole trade-off.
| Job | Files in a repository | A CMS |
|---|---|---|
| A place to write | Any text editor, or the assistant from a prompt | A form in a browser |
| Structure | Typed fields in the file. A missing field fails the build | Fields in a schema. A missing field fails on save |
| Who may change what | Whoever has the repository. Review happens in the diff | Roles, approvals, scheduled publishing, built in |
| Publish without code | Only through the assistant, or through a git-based editor on top | The point of the product |
| History | Every change is a commit with a name and a reason | Version history per item, on the better ones |
| Staging | A preview link per change, on Vercel automatically | A staging environment, on the plans that include one |
What does editing through the assistant look like?
A terminal open in the site's folder, one sentence about what should change, a diff to read, and a push. The change is live in about a minute. This is what a post looks like as a file on a site built this way: the fields at the top are the structure a CMS would give you, and the body is the content.
1---2title: "Pricing from October"3description: "What changes on 1 October and what stays the same."4published: 2026-09-255author: margus-veeber6tags: [pricing, announcement]7---89From 1 October the Studio plan is 49 EUR a month...
The prompt for a typical edit is shorter than the email that would have asked a developer to do it: "On /pricing, the Studio plan is 49 now, not 39. Update the page and the comparison table." The assistant finds both places, changes them, and shows the diff. Bulk changes are where this beats a CMS outright: renaming a feature across forty pages is one prompt and one review, not forty forms.
The same works from a phone through the assistant's mobile app, which covers the "I spotted a typo on the train" case. What it does not cover is a colleague who spots the typo and does not have the assistant, the repository, or the wish to learn either.
When does a team need a CMS?
When more than one person edits, and at least one of them should be able to fix a sentence without opening an AI tool. That is the line. A marketer changing a headline, a founder correcting a price, a support person updating an FAQ: none of those should need a prompt, a diff and a push. A CMS gives them a form, a preview and a publish button, and gives you roles so the form cannot break the page.
- Several people edit, and some of them will never use a terminal or a chat tool for it.
- Content needs a workflow: drafts, approval, a publish date in the future, a legal check.
- The same content goes to more than one place: the site, an app, an email, a partner's site. Then it wants a headless CMS with an API, like Sanity, Storyblok or Payload.
- The content has relationships: products with variants, authors with articles, locations with opening hours. Files can model this, but the CMS validates it on save rather than at build time.
- More than one language, and translators who work in a tool, not in files.
Which way should you go?
Three questions in order. Who edits decides whether files are enough. Where the content goes decides whether the CMS needs an API. Whether editors want to see the page decides between a visual builder and a CMS inside the code stack.
What do you lose without a CMS?
The visual preview while writing, first. You see the change after the preview link builds, not as you type. Roles and approvals do not exist unless you build them, and scheduled publishing is a cron job you own. Above all, every edit by someone who is not you goes through you or through the assistant, and that is a queue. On a client site that queue is the reason I still recommend Webflow to teams without an engineer.
- No form. Editing means a text file, a prompt, or a git-based editor bolted on top.
- No roles. Anyone with the repository can change anything, and review is a diff someone has to read.
- No scheduling, no localisation workflow, no built-in image library. Each is a choice, and some are duct tape.
- A non-technical colleague is dependent on you or on the assistant for every change, however small.
What do you gain?
One format for everything, and an assistant that can see all of it at once. On this site every entry, post and author is a typed object in one folder, so the search index, the sitemap, the llms.txt file and the structured data all read from the same data. A new post cannot be missing from any of them. There is no CMS bill, no API rate limit, and no field the editor forgot to fill in, because a missing field fails the build.
- Bulk edits are one prompt: rename a feature, fix a claim, update a price everywhere.
- The assistant reads the whole site as context, so it writes new pages in the site's own structure and voice.
- Structured data, summaries, key takeaways and author blocks are components fed by the same fields, so every page gets them for free.
- History with reasons. Every change says who made it and why, in the commit.
- Nothing to pay for and nothing to keep patched.
Is there a middle ground?
Two, and both are real. A git-based editor such as Decap or Tina puts a form on top of the files, so a colleague edits in the browser and the result is still a commit. It gives a small team the form without the CMS, and the assistant keeps working on the same files. The other direction is a CMS the assistant can drive through an MCP server, so the content lives in the CMS for the team and the assistant edits it from chat for you.
I have been running the second setup with the Webflow MCP server: quick edits without opening the CMS, even from a phone, bulk changes when a feature is renamed across pages, and pushing a page from chat. Sanity and Storyblok have their own servers, and the library's stack section marks which tools an assistant can drive. Which CMSs and builders an assistant can actually change today is its own post.
Which CMS fits a site built with Claude Code?
Sanity or Payload, today. Both connect to a site built with Claude Code in an afternoon, and both stay under the assistant's control afterwards. Sanity has an official MCP server, listed in Claude, so the assistant reads and edits content from chat. Payload lives inside the codebase, so the assistant changes the content model and the content the way it changes code. Pick between them by where the content goes.
- Sanity when the content feeds more than the site, or when editors want a hosted studio that is not in your repository. The Sanity MCP server gives the assistant the same access the studio has.
- Payload when you want one repository: the CMS, the content model and the site in the same Next.js app, a form for editors and TypeScript for the assistant. Nothing to connect, because nothing is separate.
- Webflow stays the pick when the team wants the page itself to be the form. Its MCP server is in the library too, with what it can change.
So the answer to the title is a question back: who edits? If the answer is "me, with an assistant", files are enough and simpler. If the answer includes anyone else, give them a CMS, and let the assistant use it too.
Questions people ask about files versus a CMS
Taken from what people actually ask about this, not written to fill the page.
When should I switch from files to a CMS?
When a second person needs to edit and should not have to learn the assistant or the repository to do it. The other triggers are content with relationships between items, an approval or scheduling workflow, more than one language, and content that is reused outside the site. If none of those apply, files stay simpler.
What is the best git-based CMS for non-technical editors?
Decap and Tina are the two most used. Both put a form in the browser on top of files in a repository, so an editor never sees the files and every save is still a commit. Tina shows the page while you edit; Decap is a plainer admin panel. Neither is in this library yet.
Can files handle dynamic content?
No. A site built from files is rebuilt to reflect a change, which takes about a minute on Vercel. Anything that changes per visitor or per second, a stock count, a comment thread, a live price, needs a database and a route that reads it. That is true whether the rest of the site comes from files or from a CMS.
Who are static websites for?
Sites whose content changes on a human schedule rather than a machine one: marketing sites, documentation, blogs, portfolios, a library like this one. They are fast because every page is built ahead of time, and cheap because there is no server to keep running. A shop with live stock or a community with logins is not one.
Is MDX the same as Markdown for this?
MDX is Markdown with components inside it, so a post can carry a comparison table or a key takeaways block as a component rather than raw HTML. It is what a site like this uses for anything beyond plain text. The cost is portability: an MDX file only renders on a site that has those components.
Take something with you
Every entry in the library ends in a block you can copy. Start with the skills.
Browse skills