Introduction
I didn’t set out to build a CMS.
Like many developers, I assumed the market already had enough of them.
There is WordPress. There is Strapi. There is Directus. There is Sanity. There are dozens of others.
Yet every time I started a new project, I found myself fighting the platform instead of building the product.
The more AI became part of my workflow, the more obvious the problem became.
Most CMS platforms were designed for a world that no longer exists.
1. The Plugin Problem
For years I worked in the WordPress ecosystem.
WordPress remains one of the most successful software products ever created. But modern projects often require a growing stack of plugins, integrations and custom code just to achieve basic requirements.
Need custom content modelling? Install a plugin.
Need advanced permissions? Install another plugin.
Need APIs, media management, workflows and automation? More plugins.
Every plugin solves one problem while introducing another dependency.
Eventually you spend more time maintaining the platform than building the business.
2. The Headless CMS Trade-Off
Headless CMS platforms solved many of these problems.
Strapi, Directus and Sanity all provide structured content and modern APIs.
But they often introduce different challenges:
- Infrastructure management
- Hosting costs
- Complex deployment pipelines
- Vendor lock-in concerns
- Limited flexibility in core architecture
Many projects end up carrying infrastructure complexity that feels disproportionate to their actual requirements.
3. AI Changes the Requirements
AI isn’t just another feature.
It fundamentally changes how software gets built.
Developers increasingly describe requirements in natural language.
Content teams expect structured data.
Automation systems need predictable APIs.
AI agents perform best when content models are clean, consistent and machine-readable.
Many existing CMS platforms were designed before these requirements became important.
That creates friction.
4. Why Cloudflare Became the Foundation
Cloudflare quietly became one of the most interesting application platforms available.
Workers, D1, R2 and KV provide an ecosystem capable of supporting modern applications without traditional server management.
That creates several advantages:
- Global deployment by default
- No server maintenance
- Simple scalability
- Reduced operational complexity
- Lower infrastructure overhead
The more I built on Cloudflare, the more it felt like the right foundation for a new CMS.
5. Building CloudCore CMS
CloudCore CMS started with a simple question:
What would a CMS look like if it were designed today?
Not in 2010.
Not in 2015.
Today.
The answer led to several principles:
- Cloudflare-native architecture
- Structured content first
- Developer-friendly APIs
- Built-in authentication and security
- AI-friendly content models
- Open source from day one
The goal wasn’t to build another WordPress competitor.
The goal was to create a platform that feels natural in an AI-assisted development workflow.
You can explore the project at cloudcore-cms.github.io and browse the source on GitHub.
6. What Comes Next
CloudCore CMS is still early.
Open source projects earn trust over time, not through marketing claims.
The roadmap includes better content modelling, improved developer tooling, expanded integrations and stronger AI-assisted workflows.
Most importantly, it will continue evolving based on real-world feedback.
The best software products are built alongside their users.
Conclusion
The CMS market doesn’t need another clone.
It needs platforms built for how developers work now.
AI is changing software development.
Cloud computing is changing infrastructure.
Developer expectations are changing too.
CloudCore CMS is my attempt to build for that future.
Whether it succeeds or fails, I’d rather build something aligned with where technology is going than continue working around the limitations of systems designed for the past.