For about twenty years, getting a website meant getting a CMS. The two words were almost the same purchase. When I started building, I assumed I needed one too, and I spent real time shopping for a tool before I understood the question it answered. It turns out most small sites do not need one at all, and knowing why is one of those fundamentals that saves you money and complexity for years.
The question under “do I need a CMS”
A CMS, or content management system, is software that gives you a friendly screen for writing and editing the words on your website, so you do not have to touch code to change them. WordPress is the famous one. The trouble is that “do I need a CMS” gets answered before the question is even understood, usually with a reflexive yes.
The real question hiding underneath is simpler: who edits this site, and how often? Once you ask it that way, the choice almost makes itself.
Three places content can live
Every website’s content lives somewhere. There are three common somewheres, and they line up on a single scale: how much machinery sits between a person and the published words.
Think of it like where a shop keeps its price list. You can write prices on a chalkboard yourself (simple, but you need to know how to write). You can put the chalkboard behind a little counter with a form, so a helper can update it without learning your handwriting. Or you can keep the master price list in a warehouse across town that many shops phone up for the current number. Same prices, very different amounts of machinery.
flowchart LR E[Person editing] --> F[Files in Git] E --> G[Git-based CMS] E --> H[Headless CMS] F --> S[Your website] G --> S H --> S
Files in Git. The content is written as plain text files (usually Markdown, a simple way to write formatted text) that live in the same place as the site’s code. You edit a file, save, and the site rebuilds. This blog works exactly this way. It costs nothing extra, it is fast, and it needs no outside service. The catch is that editing means being comfortable with the developer tools, so it suits a site that a developer, or a developer’s AI assistant, maintains.
Git-based CMS. This adds a friendly editing screen on top of those same files. Tools like Keystatic or Decap give you a login and a form, but when you hit save, they still write a plain file back into the project. You get the nice editor without giving up the simple, cheap storage underneath. It is a genuine middle ground, and often free.
Headless CMS. Here the content moves out of the project entirely and lives in a hosted service, which your website phones up for the latest words when it builds. Tools like Sanity, Storyblok, or Contentful live here. This is the heavy option, and it earns its weight when many non-technical people need to edit, schedule, and manage content with real roles and approvals. “Headless” just means the content store has no website of its own bolted on. It hands the words to whatever front end asks.
NOTE
The three are a ladder, not a ranking. Files in Git is not the beginner option and headless is not the expert option. They are answers to different situations. A giant newsroom on files in Git would be miserable. A one-person site on an enterprise headless CMS is money set on fire.
It comes down to who edits
The deciding factor is almost never the technology. It is the human who edits.
flowchart TD
Q1{Will a non-technical
person edit the content?} -->|no| F[Files in Git]
Q1 -->|yes| Q2{Just one editor, or
a small friendly team?}
Q2 -->|yes| G[Git-based CMS]
Q2 -->|no, many editors
with roles| H[Headless CMS]
In words: if the only editors are comfortable with code, or an AI agent handles the edits, plain files are the least machinery for the job. If a non-technical person needs to change things themselves but the team is small, a git-based CMS gives them a screen without the weight. Only when you have many editors who need logins, scheduling, and approval do you actually reach for a full headless CMS.
TIP
Start at the top of that ladder and only climb when a real person is blocked. It is easy to move content up to a heavier system later. It is painful and rarely worth it to rip out a system you never needed.
Here is the same trade laid out plainly.
| Files in Git | Git-based CMS | Headless CMS | |
|---|---|---|---|
| Where content lives | In the project, as files | In the project, as files | In a hosted service |
| Who can edit | Developers (or their AI) | Anyone, small teams | Many editors, with roles |
| Editing screen | Your code editor | A simple admin login | A full editorial dashboard |
| Cost | Free | Usually free | Free to start, paid at scale |
| Best for | Blogs, docs, dev sites | Small business, a shop | Publications, big teams |
Going deeper: what changed to make “no CMS” normal?
Two things. First, static site tools got good: a site can now be built from plain files into fast pages with no database behind it, which removed the main reason a CMS used to be mandatory. Second, AI assistants can now do the editing that a non-technical owner used to need a dashboard for. When your “editor” can write and update files for you, the whole reason a solo site reached for a CMS partly disappears. That is new, and it is why the twenty-year default is finally breaking.
Match the machinery to the people
A CMS is not a starting purchase, it is an answer to a specific human problem: someone who needs to edit without touching code. If nobody has that problem, you are buying machinery to run empty. The fundamental is to pick based on who edits, not on what sounds professional. And the tempting AI-era shortcut, letting an assistant manage plain files, is genuinely the right call for a lot of small sites, as long as you understand the trade you are making.
Match the machinery to the people, not to the fashion.
Sources
- Joost.blog: Do you need a CMS? for the “who edits, and how often” framing
- Bejamas: Astro CMS, content collections, a headless CMS, or both on the three storage models
- StackPicker: Best headless CMS for Astro (2026) for the git-based vs headless split and examples
- Mindbees: Do you really need a CMS anymore? (2026) on why the old default is breaking