tl:dr — Probably not. A CMS is useful when you have a content problem. If you just need to publish a few pages and posts, it might be more software than you actually need.
// what a CMS actually solves
A CMS solves a fairly specific problem.
You have content that changes independently of the code, and you want people to manage that content without editing the application itself.
That's useful.
A marketing team wants to publish a blog post without calling a developer. A newspaper has hundreds of articles. An ecommerce company has thousands of products. A company has multiple people creating and approving content.
Those are real problems.
A CMS is a good solution to them.
The mistake is turning that into:
"Every website needs a CMS."
That's like saying every spreadsheet needs a database.
It depends what you're doing.
// the CMS tax
A CMS isn't free.
Not just financially. There is a maintenance cost.
You have another system to host. Another set of credentials. Another API. Another deployment pipeline. Another dependency tree. Another place to configure authentication. Another thing that can break.
Then there is the content model.
You don't just write a blog post anymore.
You create a content type.
Then fields.
Then relationships.
Then slugs.
Then previews.
Then publishing states.
Then webhooks.
Then the frontend has to fetch all of it.
Eventually you've built a small distributed system so someone can write:
"I went for a walk today."
Sometimes that's exactly the right trade-off.
Sometimes it's completely unnecessary.
// my website doesn't have a CMS
This website doesn't have one.
I write the content and put it into a database.
That's basically it.
There isn't a WordPress installation sitting behind it. There isn't a separate headless CMS. There isn't a complicated editorial workflow.
The application knows what a note is.
The database stores the note.
The website displays the note.
There isn't much else to solve.
And because I built the site, I don't need a dashboard to abstract the database away from me.
The database already is the dashboard.
// but what about non-developers?
This is where CMSs become genuinely useful.
If I'm building a website for a client who needs to publish content themselves, telling them to open a database client and insert a row is obviously ridiculous.
The interface matters.
A CMS gives non-technical users a way to work with structured content without understanding how the application works underneath.
That's valuable.
But notice what happened.
The requirement wasn't:
"This website needs a CMS."
It was:
"Someone who isn't a developer needs to manage this content."
That's a much better requirement.
// the rise of the small website
Something else has changed.
AI coding tools have made it much easier to build small websites.
You can describe what you want. Generate a frontend. Add a database. Create an admin page. Deploy it.
For a small company or individual, that can be enough.
You don't necessarily need a giant platform.
You need somewhere to put the data and somewhere to edit it.
A developer can build that in an afternoon.
The interesting part is that the boundary between "application" and "CMS" starts to disappear.
Your website can just have an /admin page.
Log in.
Create a post.
Save it.
Done.
That's a CMS.
It's just one you built instead of buying.
// vibe coding changes the calculation
This is where I think things get interesting.
For years, the argument for using an established CMS was partly about development cost.
Why build a content management system when someone has already built one?
That's still true for many projects.
But the cost of building a small internal tool has fallen dramatically.
If AI can generate a database schema, an admin form, authentication and a few CRUD endpoints in an afternoon, the calculation changes.
You're no longer comparing:
CMS: £0 and five minutes
Custom system: £50,000 and six months
You're sometimes comparing:
CMS: another service with its own concepts and limitations
Custom system: a few hundred lines of code that do exactly what you need
That's a very different decision.
// the danger of building everything yourself
There is, however, an obvious trap.
Just because you can build something doesn't mean you should.
Authentication is boring until it isn't.
Permissions are easy until there are three different types of users.
Backups are easy until you need the backup.
Version history sounds simple until someone deletes an important article.
Media management becomes annoying surprisingly quickly.
Publishing workflows get complicated.
So does localisation.
So does scheduling.
So does search.
This is why CMSs exist.
Someone already paid the complexity tax.
// boring is sometimes good
There's a tendency in software to treat custom-built things as automatically better.
They're not.
A mature CMS is boring.
That's often its greatest feature.
It has been around for years. People know how it works. There are plugins. There are integrations. There are migration tools. There are people who have already solved the problems you're about to discover.
If your requirements match what the CMS does well, use it.
Don't build your own CMS because building software is fun.
That's how you end up maintaining your own WordPress.
// the smallest useful system
I think the better question is:
What is the smallest system that solves the problem?
For a personal blog, that might be Markdown files.
For my website, it might be a database and a simple admin interface.
For a five-person marketing team, it might be a headless CMS.
For a newspaper, it probably needs to be something much more sophisticated.
There isn't a correct answer.
There is only the amount of complexity you actually need.
// content is data
One reason I think this is becoming more interesting is that we're getting better at separating content from the software that displays it.
A blog post is data.
A product is data.
A case study is data.
A page is data.
The CMS is just one possible interface for managing that data.
Once you think about it that way, a CMS starts looking less like a mandatory part of a website and more like a tool you choose when the content management problem warrants it.
That's a useful distinction.
// when you probably need one
multiple people need to publish content
non-developers need to manage the site
you have a large amount of structured content
you need editorial workflows
you need drafts, approvals and scheduled publishing
you need localisation
you need a media library
content is a significant part of the business
// when you probably don't
you're the only person publishing
the site is small
content changes occasionally
you control the code
a database or Markdown files are enough
there is no complicated editorial workflow
// my prediction
I don't think CMSs are going away.
Large organisations will continue to need them. Content teams will continue to need good editorial tools. Complex websites will continue to have complex content requirements.
But I think we're going to see a lot more websites without traditional CMSs.
Small companies. Personal sites. Documentation. Landing pages. Blogs. Internal tools.
AI-assisted development makes it increasingly cheap to build a small application around exactly the content model you need.
The interesting part isn't that developers can now build their own CMS.
It's that they might not need to call it a CMS.
It can just be part of the website.
A database.
A form.
A few API routes.
That's enough.
The question was never really:
"Does this website need a CMS?"
It was:
"Who needs to manage this content, and what is the simplest system that lets them do it?"
Sometimes the answer is a CMS.
Sometimes the answer is a database.
And sometimes the answer is a Markdown file.
You don't need a CMS.
You need to solve the problem.
