Quick answer
You still need a CMS when people who don't ship the site need to publish often. AI does not replace that — it replaces the cost of writing a structured file and opening a pull request. If the people who write are the people who deploy, publish direct. If they aren't, keep the CMS.
Key takeaways
- A CMS exists so someone can change a page without a deploy. If nobody needs that, you don't need a CMS.
- AI makes Git publishing fast. It does not give a marketer a form, a draft, or a media library.
- Comparison tables, glossaries, and guides are records. They want typed fields more than a rich-text box.
- A CMS still wins for daily publishing, many editors, client-owned sites, and anything with a legal review queue.
- The expensive mistake is installing a CMS for a site that gets four updates a year.
What a CMS was actually for
A CMS is not where content lives. It is how a person who cannot deploy changes a page. The product is the form, the preview, the roles, the draft, and the media library — so marketing can publish on a Tuesday without waiting for engineering.
That job is real. Most marketing sites should still have one. The question is whether your writing workflow is that job, or whether you have been paying for a publishing desk you do not staff.
- Editors who never open a repository
- Draft, review, and scheduled publish
- A media library with crops and alt text
- The same page shape, repeated — posts, case studies, locations
What changed
Three things got cheap at once. Preview deploys mean a branch is a staging site. Typed page files mean a missing FAQ or meta description fails the build instead of shipping hollow. And AI can fill that file in the shape the template already expects — then open a pull request a human still merges.
That last part is the shift people miss. AI does not invent a new publishing model. It collapses the time between “here is the rewrite” and “the file is correct.” The model is still Git. The editor is a person with judgement, plus a model that will not invent a CMS schema for you.
It will not give legal a draft queue, a client a form, or a brand team a media library. If those are the requirement, you still need a CMS — or you are about to rebuild one badly.
Publish direct
Publish direct means the site is the CMS: one file per URL, a registry of slugs, a pull request, a preview, a merge. This is how we run Nuttifox's own compare pages, guides, and glossary — Cursor and Git, not Framer CMS. A comparison is a typed record: table rows, a verdict, FAQs. Not a blob of rich text.
The file in Git is what ships. No sync job, no “the CMS said something else.”
AEO fields stay fields. Assistants quote a quick answer you actually wrote, not a paragraph a plugin flattened.
A pull request is an editorial pass. You see the diff. You can refuse a sentence.
No second login, no plugin tax, no schema to keep in sync with the front end.
The costs are honest. Someone has to be comfortable in the repo — or comfortable asking an agent to edit it. There is no in-browser draft. Images are files. A writer who has never used Git is not unblocked; they are in a conversation with someone who has.
- Writers need repo access, or a person who will merge for them
- No scheduled publish unless you build it
- Media, alt text, and crops are manual
- A messy file is a messy page — types help, they do not write
Keep the CMS
Keep a CMS when publishing is a job, not a release. Daily or weekly posts, three marketers, a client who owns the site after handover, translations, or a legal queue — those are form problems. Git will make them slower and more political.
A form does not require a pull request. That is the whole point.
Legal, brand, and marketing can pass a post around without seeing a diff.
Crops, alt, and reuse across pages — Git can do this, nobody wants to.
If their team will edit after you leave, they need a CMS they already understand.
The costs show up later. The CMS schema drifts from the front-end types. Comparison tables get stuffed into a rich-text field and die. Preview is “almost the site.” Plugins become the product. You now have two sources of truth, and the wrong one will win on a Friday.
For a marketing site your team will edit, Framer's collections are usually the right CMS — repeating pages from records, not a second WordPress. We model those collections before visuals on Framer development. That is a different problem from running a studio blog.
Side by side
| Publish direct | CMS | |
|---|---|---|
| Who writes | People who can merge a PR, or an agent they review | People who should never see Git |
| Best pages | One-offs and structured records: compares, guides, glossary | Repeating shapes: posts, locations, case tiles |
| Speed to first draft | Fast with AI, if the template already exists | Fast once the schema exists; slow to design that schema |
| Review | Diff on the pull request | Draft states and roles |
| AEO / structure | Fields stay fields | Easy to flatten into a blob |
| After handover | The next developer owns it | The client's marketing team owns it |
| Failure mode | Nobody merges | Nobody agrees what the schema is |
How to choose
Do not start with the tool. Start with who publishes, how often, and whether the page is a record or a one-off.
- 01Name who writes next month
If it is two people who already ship the site, publish direct. If it is marketing, a client, or a rotation of contractors, you need a form.
- 02Count the updates
Four thoughtful pieces a year is a Git workflow. Two posts a week is a CMS. Be honest about the actual cadence, not the one in the kickoff deck.
- 03Look at the page shape
A comparison table, a glossary term, and a hiring guide are records with fields. A news post is a title, a body, and a hero. CMS for the second; files for the first.
- 04Decide who owns it after you
If you are handing a marketing site to a team that will edit it, build a CMS. If you are handing a codebase to a developer, Git is the CMS.
The hybrid most teams want
Most teams should not pick one tool for the whole site. The homepage, product pages, and blog are a CMS problem. The comparison pages, glossary, and hiring guides are a Git problem. Forcing both through WordPress makes the structured pieces worse. Forcing both through pull requests makes the blog stall.
“Install a CMS for the pages a non-developer will touch. Keep everything else as files. AI can draft either; only one of those needs a form.”
Chris NutbeenNuttifox
That is also the cheaper order of operations. Start on Git. Add a CMS the first time a person who should not open a repository needs to publish without you. Adding a CMS later is a weekend. Removing one you never needed is a quarter.
FAQ
Can AI replace a CMS?
No. AI can write and edit the files a site already knows how to render. A CMS is for people who should never touch those files. If your writers are not in the repo, AI just makes the developer faster — the marketer is still blocked.Is Git a CMS?
It is a content store with history, preview, and review. It is not a CMS for non-developers. Calling it one is how teams lock marketing out and then blame the stack.Should a marketing site still use a CMS?
Almost always, yes — usually the one in the tool you built in. On Framer that means collections. On a custom site it means a headless CMS or a thin admin. The people who change the copy after launch should not need a pull request.What about a studio blog or glossary?
If the same people who ship the site write it, publish direct. Structured pieces (compares, terms, guides) stay cleaner as typed files. Add a CMS when a second team starts publishing without you.When should we add a CMS later?
The first time someone who should not open Git needs to publish this week. That is the signal. Until then, files plus a preview deploy are enough.Have something to build? Let’s ship it.
Book a call