CMS platforms were invented for a world where developers were scarce, deployments were risky, and "digital" mostly meant "our website." To protect against those constraints, we embraced monolithic systems full of templates, roles, permissions and plugins.
But the world has moved on. We now have modern deployment pipelines, design systems, and AI. The original reasons for the CMS to sit at the centre of your stack have disappeared – yet the complexity and rigidity remain.
This is why we've stopped building for a CMS. What we build instead is a fast, flexible content operation where AI, automation and professional teams make the CMS layer essentially irrelevant.
Let's unpack that.
1. Why the CMS existed in the first place
Classic CMSs were a rational response to three old constraints:
Developers were the bottleneck.
If every content change required a code deploy, the website ground to a halt. A CMS let non-technical editors change copy and images without calling a developer.
Deploying was scary.
Shipping code to production was slow, manual and fragile. A typo in the wrong place could take the whole site down. CMS templates and strict permissions were a way to make publishing "safer."
There were only a few channels.
When "digital content" meant a handful of web pages, it was fine to bundle content, layout and delivery into one big box.
Those problems absolutely justified a lot of engineering effort and a lot of process. The industry responded with giant platforms – WordPress, Adobe Experience Manager, Sitecore, Drupal, and an entire universe of plugins and modules.
The CMS has become the default. "Of course you need one" is rarely even questioned.
But that default now comes with serious costs.
2. The reality: CMSs are now the bottleneck
If you look at the latest research on how teams actually use their CMSs, a different picture emerges: complexity, fragmentation and frustration.
2.1 Multi-CMS sprawl
61% of teams say they're juggling two or more CMSs to manage their brands.
— Storyblok State of CMS report, 1,300 CMS users worldwideWhy?
- 61% use multiple CMSs to minimise delivery risk
- 44% say they need multiple systems for omnichannel delivery
- 47% need more than one CMS to support changes to their tech stack
That's a pretty brutal verdict on the "one platform to rule them all" story.
And this isn't a one-off. WP Engine's multi-year trends work showed multi-CMS usage growing by over 40% in just a few years, with the vast majority of businesses now using more than one CMS at the same time.
In other words: CMSs have become so rigid that organisations are stacking them on top of each other just to get content everywhere it needs to go.
2.2 "Our CMS is holding us back"
84% of technology leaders believe their current CMS prevents them from unlocking the full value of their content.
— Survey of 400 technology leaders, cited by HygraphThe most common complaints:
- Changes can only be made by a small group of people
- It's hard to add new content types
- It's hard to integrate the CMS with other systems
The tool that was supposed to reduce technical dependence now creates it.
3. The hidden cost: time, training and constant rebuilding
When teams talk about CMSs, they often focus on license cost. The real cost is time.
3.1 How long does a CMS project actually take?
And this isn't just theory. Hygraph's own customer research notes plainly that CMS projects often exceed their initial timelines, with migration, training and integration "adding months to a rollout."
Multiply that by the fact that:
- Teams regularly re-platform or re-implement their CMS every few years
- Many organisations are running multiple CMSs at once
…and you have a permanent, rolling project just to keep your publishing infrastructure standing still.
3.2 Training and onboarding: the invisible time sink
Modern CMSs – especially headless and composable ones – are not trivial for non-technical editors:
- Fields, taxonomies and content models have to be carefully designed up front or editors end up with confusing dashboards and broken workflows
- Onboarding editors needs its own dedicated programme
- CMS admin interfaces are tough – it takes significant work to make everyday editor tasks even reasonably smooth
- Training, ongoing maintenance and internal development time are the real budget killers – far more than the headline monthly fee
There aren't many hard numbers on "average hours per editor per year," but the qualitative evidence is overwhelming: CMS learning curves are steep, and you pay that cost again every time someone joins, changes teams, or you switch platforms.
3.3 Security and plugin overhead
That ecosystem is a strength and a risk: vulnerabilities in plugins and extensions are a constant source of patching, testing and emergency upgrades.
At the same time, analysts expect the content management software market to be worth tens of billions of dollars annually with growth above 10% a year – a sign that companies are pouring money into a category that many users say is slowing them down.
So we've normalised the idea that this is just "what publishing costs."
But what if the original reasons for all this complexity have quietly disappeared?
4. The old constraints are gone
Look at how modern teams actually ship digital experiences today:
Deployments are safe and quick.
Git-based workflows, CI/CD pipelines, preview environments and feature flags make it safer to ship a small content change via code than to let random users poke around directly in production.
Design is encoded in systems, not pages.
Most serious brands now have a design system and component library. Changing a card, a hero section or a layout pattern isn't "rebuild the site," it's "update the component and roll it out."
AI is mainstream, not experimental.
In the latest CMS usage research from Storyblok, the single most requested improvement from CMS vendors was AI-powered content creation, with just under half of respondents listing it as their top ask – and the share of users who see AI as essential has jumped significantly year-on-year.
Headless and API-first approaches are everywhere.
Multiple market forecasts now project headless CMS spending to grow at 20%+ compound annual rates and to more than quadruple over the next decade, as teams look for flexible, omnichannel-friendly ways to deliver content.
In that context, the idea that "we must pour all our content into one big admin UI so non-developers can click around" starts to look… dated.
Which raises the real question:
- What if your content didn't have to be constrained by whatever your CMS templates allow?
- What if every piece of content could be shaped by professional creatives, designers and developers – but that process was fast, cheap and largely automated?
That's the post-CMS model.
5. The post-CMS model: content operations, not content management
When we say we don't build for a CMS, we're not saying "we don't use tools."
We're saying: the CMS is no longer the centre of gravity.
The centre is content operations – a thin combination of storage, code, automation and AI.
5.1 Content as structured data + components
Instead of pushing copy into locked-down platform templates, we:
- Treat content as documents much like the original intention of the internet itself
- Render those documents based upon the latest design system
- Version everything – content and presentation – in Git, with full history, review and rollback
From a marketer's point of view, you still have "articles," "landing pages," "case studies." But under the hood, you're no longer at the mercy of:
- Legacy content types someone modelled years ago
- Template systems that can't express new layouts
- Plugin ecosystems that break whenever you upgrade
5.2 AI and automation instead of a heavy UI
The classic justification for a CMS UI was: "Editors need to log in somewhere and change content without touching code."
Today, that "somewhere" can be a swift ticket process backed by AI-powered workflows – not a giant admin screen that everyone needs training on.
Brief via ticket, not via platform.
All content requests flow through a lightweight ticketing process where they are handled by an optimal balance of humans, the "AI Navigators" and their AI tools. This ensures all content gets the same quality treatment and nothing slips through without appropriate review. BUT, it's fast. Really fast.
You can even treat the ticket like a prompt:
"Clone our pricing page for the German market, keep the structure, soften the sales tone, and propose three hero variants."
That brief goes in, a human designer reviews for the best format and briefs build with either a design or guidance, then human technologists and AI collaborate to push the content out in all its glory.
Automated workflows with human checkpoints.
Rather than building complex role hierarchies inside a CMS, you use automation to create pull requests or content change sets, route them to the right reviewers, enforce brand/legal checks, and merge when approved. The AI accelerates the work; the human ensures quality and security.
Low friction, not no friction.
New marketing hire? Instead of a three-day CMS training, they learn to submit a brief:
"Update the hero for the Black Friday campaign across the site."
The system knows what components exist and what constraints apply – but the change still passes through professional review before it's published.
Why not direct AI prompting?
The AI landscape is evolving rapidly, and in the future it may be possible to prompt systems directly for content updates. But today, the tooling for appropriate review functionality, audit trails and security measures simply isn't mature enough to mitigate all risk. A light-touch manual process – brief, generate, review, publish – gives you the speed benefits of AI with the governance your business requires.
In this setup, the "CMS" is:
- A content store (files in Git, a database, or a lightweight headless API)
- A set of APIs
- An AI/automation layer that accelerates content creation
- A swift ticket process that ensures every piece of content is reviewed
The heavyweight, one-size-fits-nobody admin UI simply isn't the star of the show anymore.
5.3 Professionals in the loop – without becoming the bottleneck
This premise is the key:
What if every piece of content passed through professional creatives, designers and developers – and that process was super quick and easy?
With AI and modern tooling, you can have exactly that:
- Designers define reusable patterns and guardrails in the design system
- Developers build components and safe extension points
- AI helps non-technical stakeholders use those building blocks without mis-using them
So instead of handing everyone a powerful but dangerous CMS UI and hoping governance will save you, you:
- Keep the source of truth with your professional teams
- Give everyone else high-level, goal-oriented controls mediated by automation
You get the quality and brand consistency of "designer-built" pages, with the speed of "editor-driven" updates – without the CMS bloat.
6. What you gain by not building for a CMS
Concretely, what changes when you take the CMS out of the centre?
6.1 Less complexity, fewer moving parts
Dropping the monolith means:
- No duplicate user-management and permissions inside the CMS
- No sprawling plugin zoo
- No multi-CMS sprawl just to cover edge cases
A post-CMS stack lets you:
- Store content in whatever simple, scalable infrastructure makes sense
- Fan it out to web, apps, email, in-product surfaces and any future channel via APIs and automation
- Swap or upgrade parts of the pipeline without rebuilding everything
6.2 Real design freedom, continuous brand evolution
Because content is rendered via your own front-end and components, you're not constrained by:
- Theme systems designed for desktop-only web
- Rigid "modules" that approximate your brand
- "Big bang" redesigns tied to CMS re-implementation
Change the headline style in your design system, and:
- Every landing page hero updates
- Every product tile refreshes
- Every layered component that uses it gets the improvement for free
You can evolve your brand continuously instead of waiting for the next mega-rebuild to turn up budget.
6.3 Faster change, lower risk
The old assumption:
"We need a CMS because code deploys are risky."
The modern reality:
- Your CI/CD pipeline + feature flags + preview URLs are better guardrails than most CMS workflows
- Git gives you full audit trails and instant rollback that UI-based edit histories rarely match
- Automated tests, accessibility checks and performance budgets can run on every change – including content changes – before anything hits production
Meanwhile, newer research on headless CMS adoption shows that when teams move away from monolithic systems to more modern, API-driven ones, the majority report improved time-to-market, productivity, performance, security and ROI.
We're just taking that decoupling logic one step further and asking:
"If the CMS is still the bottleneck, why not remove it from the critical path altogether?"
7. Common objections
"But our editors need a CMS login."
Do they need a CMS, or do they need:
- A way to request and brief content
- A way to review and approve changes
- A way to understand where content lives and how it performs
All of that can live in:
- Collaborative docs and ticketing systems
- Lightweight dashboards
- Conversational assistants powered by AI
None of those things require a monolithic CMS platform.
"Isn't building this custom stack more work?"
In the short term, yes, you're putting more thought into architecture.
But compare that to:
- Multi-month CMS implementations and migrations you repeat every few years
- Ongoing training, plugin updates, security patches, and integration fixes
- The opportunity cost of editors fighting their tools instead of shipping content
A lean content-ops stack is intentionally small:
- One design system
- One or two simple content stores
- One front-end
- A layer of automation and AI
You invest once in these fundamentals and evolve them continuously, instead of jumping between CMSs every time your needs change.
"Isn't this just 'headless CMS' with extra steps?"
Headless CMS platforms are a big improvement over old-school monoliths, and their market is growing fast. But even the nicest headless tools still:
- Ship with heavy admin UIs
- Require extensive modelling and configuration
- Need training and governance
- Often end up duplicated across teams and regions
We're arguing for something lighter:
- Treat content storage as infrastructure, not as a giant all-in-one product
- Let AI and automation be the "interface" humans use
8. So what replaces the CMS?
In practical terms, a post-CMS setup usually looks like:
Content storage
- Markdown/MDX or JSON in Git for long-form content
- A simple database or headless service for structured data
- Object storage for media assets
Technology & delivery
- Design system translated into stylesheets and components
- Return to the simplicity and robustness of integrated applications rather than a decoupled nightmare: extracting the frontend and the backend into seperate apps then connecting them together with APIs then building a whole new, incredibly complex system to recouple the frontend and backend to render on the server so that Googlebot can crawl it...
- Edge caching and CDN
Automation & AI
- Agents that understand your components and content schemas
- Workflows that turn natural-language requests into structured changes
- Automated checks for accessibility, performance, SEO and brand tone
Governance & analytics
- Git and issue trackers for workflow and audit
- Observability and analytics built into the front-end and data layer
- Simple dashboards that answer "where does this live?" and "is it working?"
No giant admin area. No "CMS training" as a permanent budget line. No rebuilding your publishing stack every time the market shifts slightly.
9. Conclusion: content without a central cage
CMSs did their job. They solved real problems in an earlier era of the web.
But we've moved on:
- Deployments are safe and automatable
- Design systems encode brand and layout far better than templates
- AI and automation can put professional creative and engineering quality within reach of every content change, without forcing non-technical people to wrestle with complex UIs
Given all of that, the honest question is:
If you were designing your publishing stack from scratch today, would you really invent a giant CMS in the middle of it?
Our answer – and the reason we don't build for a CMS – is no.
We'd build lean content operations instead:
- No user-management overhead inside yet another platform
- No design limitations imposed by yesterday's templates
- No years-long rebuilds just to catch up with where your brand already wants to go
Just content, passing quickly and safely through professional creatives, designers and developers – guided by AI, shaped by your design system – and never again trapped inside a CMS-shaped cage.
Ready to move beyond the CMS?
Let's talk about how we can help you build a modern content operation that's fast, flexible, and free from CMS constraints.
Book a consultation