Opening Webflow, WordPress, or HubSpot to click text and upload images can feel archaic if you already manage content the same way you write front-end code. For a small technical team, that upgrade is real. Markdown in a repository, reviewed in a pull request, optionally edited by an agent that can write files, is a better developer experience than a seat-licensed visual editor.
Treating that upgrade as proof that the CMS category is finished still confuses the editor with the system. One is an authoring surface. The other is storage, governance, and a publish path for people who will never open a pull request.
What a CMS actually bundles
A content management system usually does three jobs at once. It stores structured content. It gives non-developers a way to edit and publish. It renders (or feeds) the pages visitors see. WordPress, Webflow, HubSpot, and similar platforms sell that bundle. Headless products sell the first two and leave rendering to your application.
The part worth paying for is rarely the text field itself. It is draft and published states, scheduling, per-author permissions, a review step, and a history of who changed what. If your organisation needs that layer, you are buying something real. If you do not, you are renting a dashboard to get storage you could keep in git.
When git and markdown are enough
For a founder-led site, a documentation set, or a blog owned by developers, markdown (or MDX) in a repository is still a CMS, just with a different editor. Diffs are readable. Reviews happen where code already happens. AI tools that edit files fit the same loop. You avoid seat fees and a second product to keep patched.
Lee Robinson’s write-up on coding agents and complexity budgets is a clear example of that bet: moving a marketing site off a hosted CMS into markdown and repository workflows so agents can change content the same way they change code. The win is a thinner stack for a technical publisher. It is not proof that every client team can publish the same way.
That workflow fails when the people who must publish will not touch a repository, a terminal, or a chat prompt that writes files. Training them might be possible. Choosing a workflow they will not use is still a failed project. The useful tool is the one that ships on schedule with the team you have, not the one that looks cleanest in a developer timeline.
When you still need the editorial layer
A CMS (bundled or headless) still fits when several people publish weekly, when legal or brand review must happen before go-live, when localisation or multi-site ownership matters, or when marketing must ship landing pages without waiting for a deploy window. Those are governance problems. A prettier WYSIWYG does not create them, and deleting the dashboard does not dissolve them.
CMSWire’s reporting on headless meeting real marketing workflows describes the same pressure from the other direction: API-first delivery helps engineers, yet many marketing teams still need preview and visual editing if publishing is not meant to wait on a deploy queue. Hybrid or “capability, not purity” setups show up for that reason. The category question is who must ship, not which architecture diagram looks cleanest.
File-based content can grow into the same needs: branches, preview environments, role checks in CI, and an approval bot. At that point you have rebuilt half a CMS around git. That can be the right architecture. It is not “no CMS.” It is a different CMS shape. Knut Melvær’s response to the markdown migration story makes that point explicitly: asset handling, permissions, localisation, and content relationships tend to reappear as custom tooling once the site stops being a handful of pages.
Agencies still inherit client CMS sites
Agencies do not get to declare the category dead. Clients open WordPress, Webflow, or HubSpot on Monday whether or not your own marketing site is markdown. The portfolio problem is keeping checkout, pricing, and other priority URLs fast while editors keep publishing through the tools they already know. Rip-and-replace every retainer onto a monorepo is not a monitoring strategy. It is a migration fantasy.
Watcher’s lane stays beside that reality: continuous PageSpeed and Core Web Vitals evidence across many domains, not a replacement CMS. Monitoring layers onto the stack clients already use; their visual editor does not become optional because your content lives in git. For the ritual side of that work, the Core Web Vitals monitoring checklist for agencies is the shared starting point we still argue about in practice.
The archaic habit is theme-clicking, not having a CMS
What feels outdated on many accounts is not “someone used a CMS.” It is treating the visual editor as the performance plan: new theme, another page-builder widget, another plugin, while field Core Web Vitals stay red. Editors need a place to work. Engineers still need a queue of URLs that fail lab gates, third-party weight that steals the main thread, and a domain report that ranks attention before anyone debates fonts.
A more reliable triage starts from a domain-level signal when pages need attention, rather than a single homepage paste and a theme swap. Our write-up on the attention-free score and domain report Summary is the shape we use. When plugins and tags dominate the waterfall, the patterns in third-party scripts that hurt performance usually matter more than the CMS brand on the invoice.
FAQ
Is markdown in git “not a CMS”?
It is still content management: store, edit, publish. The editor is the IDE and the pull request. The system is the repository plus your build and review rules. Calling it “no CMS” only hides that you moved the jobs into git.
Are CMS vendors finished because AI can edit files?
AI helps authoring, especially when content already lives as files an agent can change. It does not by itself give you permissions, scheduled release, audit history, or a safe path for a non-technical editor. CMSWire’s piece on what happens when AI agents inherit a messy content repository makes the same cut: more generated pages do not fix weak source content, ownership, or freshness rules. Agents work better as a complement to governance than as a substitute for it.
Should agencies move every client off WordPress or Webflow?
Only when the client’s team, budget, and risk appetite support a migration. Most retainers need faster priority URLs and clearer reporting on the CMS they already run. Monitoring and budgets scale across that fleet; forced platform rewrites do not.
Does Watcher replace a CMS?
No. Watcher monitors PageSpeed and Core Web Vitals across sites. It layers onto WordPress, Webflow, HubSpot, custom stacks, and static sites alike. The CMS remains where editors publish; monitoring is how you notice when that publishing hurts the field scoreboard.
What to do next
For a solo technical publisher, writing content like front-end code is a legitimate CMS choice. For marketers, clients, or a multi-author team, a real editorial layer still matters, and a clunky visual editor is not the same as the whole category. Separately, scheduled performance evidence helps theme and plugin debates follow data. Try Apogee Watcher when you need multi-site PageSpeed monitoring beside whatever CMS each client already uses.
References
- Coding Agents & Complexity Budgets (Lee Robinson)
- “You should never build a CMS” (Knut Melvær / Sanity)
- More AI-Generated Pages Won't Save Your CMS Strategy (CMSWire)
- Is Headless CMS on a Course Correction? (CMSWire)
- Attention-Free Score: How Domain Reports Show Which Pages Need Work (Apogee Watcher)
- Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders (Apogee Watcher)
- Core Web Vitals Monitoring Checklist for Agencies (Apogee Watcher)
Top comments (0)