“You should never build a CMS”
58 comments
·December 14, 2025inesranzo
gregates
It seems like the argument is roughly: we used to use CMS because we had comms & marketing people who don't know git. But we plan to replace them all with ChatGPT or Claude, which does. So now we don't need CMS.
(I didn't click through to the original post because it seems like another boring "will AI replace humans?" debate, but that's the sense I got from the repeated mention of "agents".)
arionmiles
Cursor replaced their CMS because Cursor is a 50-people team shipping content to one website. Cursor also has a "Designers are Developers" scenario so their entire team is well versed with git.
This setup is minimal and works for them for the moment, but the author argues (and reasonably well enough, IMO) that this won't scale when they have dedicated marketing and comms teams.
It's not at all about Cursor using the chance to replace a department with AI, the department doesn't exist in their case.
gregates
> Lee's argument for moving to code is that agents can work with code.
So do you think this is a misrepresentation of Lee's argument? Again, I couldn't be bothered to read the original, so I'm relying on this interpretation of the original.
ozim
I do believe that using Git GUI for those people should be perfectly fine and it would be good for business people in general to adopt Git for a lot of documents or content.
But forcing people to use the tool is not the way to go as ROI depends a lot on context of the company and lots of time just a CMS would be better bang for the buck.
PunchyHamster
Git can make sense, but you still need to wrap it for non-technical people. No matter how easy markup is, some people still will refuse to learn it and ask for WYSIWYG tools
sublinear
I'm gonna be honest here. I don't know what a non-technical person is anymore. The only people I can truly label that way are a subset of the people now near or at retirement age.
It's almost 2026. There are more people who know how to code than ever before. This stuff is taught in every school now. Everyone has access to AI to help them if they get stuck. If someone under 50 is unwilling to work I am unwilling to employ.
weitendorf
A huge number of those people only interact with computers as a consumer. Beyond that, maybe schools assignments, texting and other social media, light email, and video games (eg through steam or a console). There is a big gap between that and someone comfortable using git.
Don’t be an asshole to them about that, think about how many developers would do anything it takes to avoid calling someone on the phone. Obviously they can learn it, but they know they’re going to be bad at it for a while (true for both git and phone calls) and they don’t know how long it’s going to take, or the extent of what they don’t know.
The thing about software companies is that they know how to automate and build stuff so why invest the time in learning a CMS if it’s something they could quickly solve for their own use case? Well, the same applies to people who just want to point and click and write, wondering whether it’s worth it to learn what a rebase does.
d--b
Ah, this is fun.
The article is about how people shouldn’t build CMSs because they’re building things that are too simple, missing tons features and not realizing the scope of what they get into.
But one thing that CMSs may want to have is “proper version control”. So what do they do? They are faced with 2 options: using a complete version control system like git, which allows them to do branches and merges and PR reviews and so on. Or they build something simpler internally, with only draft/publish, like they usually do.
But what if 2 marketers are making changes to the same file at the same time? one because the name of a product changed, and one because there is a new christmas sale. Does the version system handle merging? Maybe… maybe not…
The point I am making is that we always make the tradeoffs of buying off-the-shelf complex stuff vs internally built, incomplete buggy but tailor-made solutions.
And CMS is very much a space where customability matters.
BTW, Github Pages is a git-backed “CMS” used by millions of people. It works fine.
JSR_FDED
I thought this was a classy response. It’s very hard to address the original points of criticism without coming across as too defensive, but he managed to do it well. On top of that the author is kind of speaking on behalf of the whole CMS industry, which when all taken together certainly has a lot of issues. He made a good case for his product without trashing his competitors.
RobotToaster
This is written by a proprietary CMS company, so they may be slightly bias.
kmelve
Author here! Of course, I'm biased!
But in that bias is a ton of experience in the CMS field and a lot of observation of actual teams trying to solve for content operations challenges. I think that's valuable to share, even if we happen to also sell a solution to these things.
mmcnl
The original article was written by an employee of an AI company, demonstrating that a CMS is not really needed when you can use AI. Both are probably biased, but nonetheless both articles are worth a read. Re-evaluating established patterns in the age of AI is an interesting thought exploration, from both sides.
null
larusso
This story reminds me of a similar issue people love to solve with the same idea. Software builds. The can’t we have a simple make file or worse just a shell script to build.
And just like described in the post it starts the same. Simple script wrapper. No tasks no tasks dependencies. Then over time you need to built now a library which contains the core part of the software to share between different other projects. You need to publish to different platforms. Shell scripts become harder to use on windows all of a sudden. You need to built for different architectures and have to integrate platform specific libraries. You can built your simple make / shell file around all that. But it ain’t so simple anymore.
kstenerud
The idea is to have an 80/20 build system:
For the 80% of use cases, you have homogeneous build commands that are the same across projects (such as a makefile with build, clean, test, etc). This calls the real (complex) build system underneath to actually perform the action. You shouldn't need to type more than 15 keys to make it do common things (and you CERTAINLY shouldn't need to use ANY command line switches).
Then for the other 20% of (complex) use cases, you call the underlying build system directly, and have a document describing how the build system works and how to set up the dev environment (preferably with "make dev-env"). Maybe for self-bootstrapping systems like rust or go this isn't such a big deal, but for C/C++ or Python or node or Java or Mono it quickly becomes too bespoke and fiddly.
Then you include tests for those makefile level commands to make sure they actually work.
There's nothing worse than having to figure out (or remember) the magical incantation necessary to build/run some project among the 500 repos in 15 languages at a company, waiting for the repo owner to get back to you on why "./gradlew compileAndRun" and "/.gradlew buildAndRun" and "./gradlew devbuild" don't work - only to have them say "Oh, you just use ./gradlew -Pjava.version=11 -Dconfig.file=config/dev-use-this-one-instead.conf -Dskipdeploy buildAndDeploy - oh and make sure ImageMagick and Pandoc are installed. They're only used by the reports generator, but buildAndDeploy will error out without them". Wastes a ton of time.
01HNNWZ0MV43FF
Having Make shell out to the real build system is a nice compromise. Then you can stick your tests and stuff in there too
odie5533
I think there is a need for Agent-first tooling for things like CMS.
> Previously, we could @cursor and ask it to modify the code and content, but now we introduced a new CMS abstraction in between.
That is a very real benefit to having everything accessible by Agents. Whenever I need to setup connections in web UIs, it slows me down. IaC is a huge step in the right direction for Agent workflows, but so much is still locked away like CMS management, Confluence docs, Jira tickets, etc.
null
finaard
I think it's good practise to build something CMS like for fun - as long as you don't expect it to be useful or used, outside of maybe your personal page. It's useful to experiment and learn stuff that might be useful at scale in other projects.
I intentionally made a few interesting choices for my stuff, just to see how far you can push it, and to make sure no sane person would ever use that in production (like, from before Markdown was around, I was wondering how far you can get with doing a simple markup language parsed by using regexp only. Turns out, surprisingly far, but if something doesn't parse as expected later on you have a bit of a problem)
ianberdin
UI first approach is dying. I don’t even want to touch it if possible, if cursor can solve it for me.
beezlewax
Can you give some examples of this?
swazzy
I believe the point is that AI or cursor/agent is your CMS. The points about structured content and references are valid but go away as AI improves.
ozim
Part on Git not being content collaboration tool is just wrong.
Code merges are extremely semantic. Changes over multiple files/places in project are the norm.
Feels like author went on defensive mode against Git. But he is quite right on other points.
Why do you need to use Git as a CMS?
That seems backwards and hellish when you want to grow your content and marketing team as they have no clue on how to use this arcane tool.
Now the engineers would need to be bothered by the marketing department time and time again to add blog posts, wasting engineering time.
This is the reason why CMS's like Sanity, Wordpress, Directus exist.
using Git as a CMS doesn't make sense at scale.