Let me save you a meeting. If your technology team is currently debating "headless vs traditional CMS" as though it's a binary choice - pick a side, commit, move on - the framing is wrong. And the wrong framing is probably why the decision keeps getting deferred.
I should say upfront: Distinction is a Kentico partner. I'll be specific about Kentico's hybrid model later in this piece because it's the clearest example I know of the architecture I'm describing. But the argument itself - that hybrid is the right fit for most mid-market B2B service firms - holds regardless of vendor. If you end up choosing a different platform that does hybrid well, this article has still done its job.
Right. Let's untangle this.
I'm going to explain this in terms of what each model means for the two groups of people who actually have to live with the decision: your content editors and your development team. Not architecture diagrams.
Traditional CMS. Content and presentation are bundled together. Your editors write content, preview it, hit publish, and it appears on the website looking exactly as they expect. This is what most people picture when they think "CMS" - it's WordPress, it's classic Umbraco, it's what your current site probably runs on. Editors love it because what they see is what they get. Developers tolerate it because it works, but they're constrained. Want to deliver that same content to a mobile app, a client portal, and a partner microsite? You're essentially rebuilding each time. And modern front-end frameworks? Good luck bolting React onto a system designed around server-rendered page templates.
Pure headless. Content and presentation are fully separated. The CMS becomes a content repository with an API - a structured bucket of content that doesn't know or care how it gets displayed. Your development team builds whatever front-end they want, in whatever framework they want, pulling content via API calls. Maximum flexibility. The catch? Your editors are now writing content into what often feels like a spreadsheet. No preview. No visual page builder. No intuitive sense of what the finished page looks like. And every new channel or page template requires development work. You haven't eliminated complexity - you've moved it from the CMS to the front-end team.
Hybrid. This is the one most people haven't properly evaluated, because it doesn't have the same marketing energy behind it. A hybrid CMS gives editors a familiar, visual content management experience - page builders, preview, drag-and-drop components - while also exposing content through APIs for headless delivery. Your marketing team publishes a thought leadership piece using a WYSIWYG editor. Your development team simultaneously pulls that same content into a client portal via API. Same content, different delivery mechanisms, nobody's fighting the architecture to do their job.
That's genuinely it. Three models. The question is which one fits your team, your requirements, and - this bit matters more than most technology evaluations acknowledge - your realistic development capacity.
"Headless" has done the same thing "cloud" did about a decade ago. It started as a specific architectural concept, got picked up by marketing departments, and turned into a vague proxy for "modern." Honestly, it's doing my head in. I've sat in steering committee meetings where a CTO says "we need to go headless" with roughly the same specificity as a CEO saying "we need to be more digital" in 2015. It sounds right. It sounds forward-looking. But it doesn't actually describe a decision.
Here's what happened. The headless CMS market is growing fast - around 22.6% CAGR - and every vendor wants a piece of that. So platforms that are really traditional with an API bolted on call themselves "headless-capable." Platforms that are genuinely headless-first position themselves as the only serious option. And technology leaders in mid-market firms - firms with maybe three to five developers and a content team of two or three - end up evaluating architectures designed for engineering teams of fifty.
The question was never "headless or not." It was always: how much of your architecture should be decoupled, for which specific use cases, and does your team have the capacity to maintain what you're building?
"Headless is the future. Everything else is legacy."
I hear this a lot. And I get the appeal - it's a clean narrative. But it confuses a direction of travel with a destination. Yes, the trend is toward more decoupled, more composable architectures. That doesn't mean every firm needs to be fully decoupled right now, any more than "the future is electric vehicles" meant you should have bought a Tesla in 2014 when there were six charging points between London and Birmingham.
For most mid-market B2B service firms - and I mean the consulting firms, law firms, financial services businesses, and SaaS companies we typically work with - hybrid is the right starting point. Not because it's a safe compromise, but because it matches how these firms actually operate.
You probably recognise at least one of these scenarios.
Your marketing team needs to publish content without filing a ticket. They want to update a service page, publish a case study, build a landing page for an event - and they want to do it this afternoon, not in the next sprint. A pure headless CMS makes this harder, not easier. We had a financial services client a while back - about 350 people, decent in-house dev team, genuinely excited about going headless - who migrated to a pure headless platform and were six months in before anyone admitted it had gone sideways. Their two content editors were raising Jira tickets to change a headline. The marketing director called me and said, quite bluntly, that she wanted her old WordPress site back. That's not a technology failure. That's a mismatch between architecture and the people who have to live with it every day.
Your development team needs to deliver content beyond the website. Maybe you're building a client portal. Maybe you want to feed CMS content into personalised email sequences via your CRM. Maybe you're thinking about how AI agents will need structured access to your content in eighteen months. A traditional CMS makes all of this painful. A hybrid model gives your developers API access to the same content your editors are managing through a visual interface.
You need to integrate with other systems without building everything from scratch. CRM, marketing automation, client portals, personalisation engines - the average mid-market firm has somewhere between eight and fifteen systems that need to talk to each other. A hybrid platform with native APIs and pre-built integration points cuts the custom development overhead significantly. We watched one firm spend the better part of six months building custom API layers for a pure headless setup that a hybrid platform would have handled out of the box. Six months. For plumbing.
There's a broader pattern here too. Two-thirds of large technology programmes miss their targets on time, budget, or scope. Complexity is the enemy, and pure headless adds complexity that most mid-market firms underestimate at the evaluation stage and discover at the implementation stage.
Now - and this is important - there are firms where hybrid is genuinely the wrong answer. I'd be doing you a disservice if I glossed over this.
If you have a mature, well-resourced in-house development team that actively wants full control of the front-end stack, pure headless gives them that control without the constraints of an opinionated CMS layer. These are typically firms where the development team is ten-plus people, they're already working in modern JavaScript frameworks, and they view the CMS as a content store - nothing more. Forcing a visual page builder on this team would feel like putting training wheels on a racing bike.
If you're building a digital product - a client-facing platform, a SaaS application, a complex portal where the CMS content is one data source among many - then the structured, channel-agnostic content model of a pure headless CMS is often the right foundation. The front-end isn't "a website." It's an application, and it needs to be architected like one.
And if your content delivery requirements are genuinely varied and complex - content flowing to web, native apps, IoT displays, third-party platforms, partner integrations - a hybrid model's opinionated page-builder structure can become a constraint rather than a benefit. When the CMS's concept of "a page" doesn't map to how your content actually gets consumed, you need a purer separation.
I've written about Payload CMS separately as an example of what a pure headless architecture looks like done well - if you're evaluating that end of the spectrum, it's worth reading alongside this piece.
The honest test: if you removed the visual editing layer entirely and your team wouldn't miss it - because they're building everything in code anyway - pure headless is probably your fit. If your content team would revolt, it probably isn't.
So what does hybrid actually look like when it's implemented, not just described in a blog post? Kentico Xperience is the clearest example I can point to, so let me get specific.
Kentico splits its content architecture into two distinct areas: Pages and Content Hub. Pages are the traditional side - structured, visual, preview-able content tied to specific URLs on your website. Your marketing team builds and manages these through a page builder with drag-and-drop components, live preview, and workflow approvals. If you've used a traditional CMS, this feels familiar. It works how you'd expect.
Content Hub is the headless side. Structured content items - case studies, team bios, service descriptions, FAQs - that aren't tied to any specific page or channel. They're managed in the CMS but delivered via API to whatever needs them: your website's front-end (built in Next.js or whatever your team prefers), a client portal, a mobile app, a personalisation engine. The Content Hub UI isn't going to win any design awards, if I'm honest. But it does the job, and editors get used to it quickly enough.
Here's why this matters practically. A technology leader evaluating Kentico can start with a largely traditional setup - Pages handling the website, editors working in the visual builder - and progressively introduce headless delivery as requirements evolve. Need to feed content to a new client portal? Use Content Hub and the API. Want to rebuild the front-end in a modern framework? Decouple it from Pages and pull content via API instead. None of this requires a platform migration. You're not choosing between "headless now" and "headless never." You're choosing "headless where and when it makes sense."
This progressive decoupling is, honestly, the most valuable thing about the hybrid model for mid-market firms. Research suggests around 68% of organisations find legacy systems obstruct AI adoption. Having a content architecture that can expose structured content via API means you're not rebuilding your CMS when AI-driven personalisation or agentic workflows become practical requirements - and that's coming faster than most firms' planning cycles account for.
If you want the broader evaluation of Kentico as a platform - beyond the architecture model - there's a companion piece on why Xperience by Kentico is a smart choice for mid-market firms that covers the full picture. And if you're at the stage of comparing Kentico against alternatives, we've also written about how Kentico stacks up against competitors across the things that actually matter in practice.
Here's what I keep seeing, and it's honestly the thing that prompted this piece. Technology leaders in mid-market firms who understand the headless vs traditional question well enough to know it's complicated, but not well enough to feel confident making the call. So they defer. They extend the existing platform contract for another year. They patch what they've got. They tell the board they're "evaluating options."
I had a conversation a few months ago with a CTO at a 200-person consulting firm. Smart person, genuinely across the technical considerations. They'd been "evaluating" CMS options for fourteen months. Fourteen. The existing platform was creaking, the content team had developed an elaborate system of workarounds, and two developers were spending a combined day a week on maintenance that a modern platform would have automated. But the decision felt too complicated to make, so it kept not getting made.
That deferral has a cost. Not a dramatic, everything-breaks cost - a quiet, compounding one. The content team works around CMS limitations instead of publishing effectively. The development team spends time maintaining integrations that a modern platform would handle natively. The firm's digital experience falls a little further behind what clients encounter everywhere else. Your next CMS decision matters more than you might think - I've written about why separately, and it's worth reading if you're in this holding pattern.
The hybrid model is worth understanding not because it's a magic answer, but because it resolves the specific dilemma that's causing the deferral. You don't have to choose between editorial usability and architectural flexibility. You don't have to staff up a large development team to go headless, and you don't have to accept the constraints of a traditional CMS to keep your editors productive.
If you want to work out which delivery model is the right fit for your team's capability and your firm's digital requirements, we've put together a CMS architecture decision guide that maps the decision across the three scenarios - traditional, hybrid, and headless - against four variables: development capacity, editor needs, multi-channel requirements, and integration complexity. It's designed to be something you can share with your steering group and actually have a useful conversation around, rather than another sixty-page analyst report that sits in someone's inbox.
Making no choice is, reliably, the most expensive option.