CMS Chat vs Headless CMS: Do You Really Need to Retrofit Sanity or Contentful?

The Question Every Agency Hits After Launch

You shipped a custom-code site. Next.js, Astro, Hugo, whatever your stack is. It's fast, it's clean, and the content lives where developers like it: in the repo.

Then the client asks how they change the opening hours.

The standard answer in 2026 is "we'll add a headless CMS." Sanity, Contentful, Storyblok — all excellent products. But "add a CMS" is a much bigger sentence than it sounds, and for a lot of client sites it's the wrong-sized tool. This post walks through what retrofitting a headless CMS actually involves, when it's worth it, and when letting clients edit the repo directly by chat gets you the same outcome with none of the migration.

What "Just Add a Headless CMS" Actually Involves

Content Modelling

A headless CMS doesn't know what a "hero headline" or a "team member card" is until you tell it. Someone has to break every editable piece of the site into fields, types, and relations. For a finished site, that means reverse-engineering your own components into a content schema — often days of work for a site the client thinks of as "done."

Wiring Every Component

Once the schema exists, every component that should render CMS content needs to fetch it. That's queries, loading states, preview modes, and environment plumbing — across the whole site. Miss a component and you get the classic split-brain site: half the content in the CMS, half still hardcoded, and nobody remembers which is which.

Another Dashboard to Train Clients On

The end result of all that work is a new admin UI your client has never seen. Field names they don't recognize, a publish flow they need explained, and a login they'll forget. The training problem you were trying to solve moves — it doesn't disappear.

Ongoing Cost and Coupling

Headless CMS pricing scales with seats, locales, and API calls. And once content lives in the CMS, the CMS is load-bearing: exports are possible, but leaving is a project of its own.

When a Headless CMS Is the Right Call

To be fair to the category — sometimes it genuinely is:

• Content-first products. Publications, docs platforms, multi-brand marketing systems with hundreds of structured entries. Content modelling pays off because content IS the product.
• Many non-technical editors working in parallel. Editorial workflows, roles, and scheduled publishing are what these tools are built for.
• Content reused across channels. If the same entries feed a website, an app, and email campaigns, an API-first content store earns its keep.

If that's your situation, use one. The rest of this post is about the other situation — the one most agency client sites are actually in.

The Other Situation: A Finished Site That Needs Small Edits

Most client sites don't have an editorial team or multi-channel content. They have one owner who occasionally needs to change text, swap a photo, update a price, or fix a phone number — and an agency that currently does those edits by ticket.

For that shape of problem, CMS Chat skips the retrofit entirely:

• No migration. The repo you already shipped stays the source of truth. No schema, no content modelling, no wiring pass across components.
• No new dashboard. The client types what they want changed in plain language: "change the headline on the homepage to X." No field names, no publish flow to learn.
• Every change is a Git commit. Edits land in the repository you own, visible in your normal history and review tools. Your developer can see and reverse anything the way they'd handle any other commit.
• Guardrails instead of roles. Clients can only touch content inside zones your developer marked safe. Layout, code, and SEO-critical elements stay locked or escalate to your team as a pull request.

The honest trade-off: CMS Chat is built for Git-based stacks. If your site isn't in a repo, or you need structured multi-channel content, it's not your tool.

Side by Side

| | Retrofit a headless CMS | CMS Chat | |---|---|---| | Setup on a finished site | Days to weeks (schema + wiring) | Connect the repo, mark safe zones | | Where content lives | The CMS's datastore | Your Git repo | | What the client learns | A new admin dashboard | Typing what they want changed | | Who handles risky edits | Role permissions, hopefully | Escalation to your team as a PR | | Leaving later | Content export project | Cancel; the repo keeps its history |

The Short Version

"Why not just add a headless CMS?" is the right question — and for content-heavy products, the right answer. But for the typical agency client site, retrofitting one means restructuring content into fields, wiring every component, and training the client on yet another dashboard, all to enable edits that a chat message can express in one line.

If the site is in Git and the goal is "clients stop sending content tickets," the shorter path is to let them edit the site by chatting, with your team keeping the commits and the final say.

CMS Chat is in private beta — we onboard agencies in small waves. Put your agency in the next wave.