There's a recurring conversation we have with clients early in a project. Someone has come in having read the right articles, talked to the right developers, and landed on a conviction: "we need to go headless."

Sometimes they're right. Often, they're solving a problem they don't actually have yet - and creating several new ones in the process.

After building and maintaining websites for B2B tech companies for years, our take on CMS architecture isn't ideological. It's situational. Headless has real strengths. It also carries real costs that don't show up in the vendor demos.

Here's how we think about it.

What headless actually means, and what it's designed for

A headless CMS decouples where content is stored from where it's displayed. Your content lives in a backend system (Contentful, Sanity, Strapi, and others are common choices), and you pull it into any frontend you want via API. That "any frontend" is the point: the same content can feed your website, your mobile app, a digital kiosk, a voice assistant, whatever comes next.

This is a genuinely powerful architecture - when that flexibility is the actual requirement.

The pattern it's optimized for is omnichannel publishing: organizations that need the same content structure to power multiple distinct surfaces simultaneously. A media company pushing articles to a web app, a native app, and partner syndication feeds. A retailer with product content flowing to a storefront, an in-store display, and a third-party marketplace. That's where headless earns its complexity.

For a B2B SaaS company running a marketing site with a blog, a resource library, and a handful of landing pages? The architectural flexibility of headless is almost never the bottleneck.

The tradeoffs that don't get mentioned in the pitch

When a developer proposes a headless stack, they're optimizing for their experience, and that's legitimate. Clean APIs, freedom to choose frameworks, no fighting with a monolith. The developer experience is genuinely better.

The organizational experience is often another story.

Publishing becomes a pipeline, not a button. In a traditional or visual CMS, clicking publish sends your content live. In a headless setup, a content change typically triggers a webhook, which kicks off a build process, which deploys to a hosting provider, which then clears cache. When it works smoothly, no one notices. When any step fails, and they do fail, tracking down where things broke requires technical involvement.

Marketing teams lose autonomy. Marketers can update copy inside the CMS fields. What they can't easily do is change a page layout, add a new section type, or restructure a landing page without a developer creating the template first. Every new content shape requires engineering work. For teams running campaigns or doing frequent conversion optimization, this creates a chronic dependency that slows everything down.

The stack grows, and so does the maintenance surface. Headless promises composability, which sounds like a feature until you're maintaining eight integrations. You need the CMS, a frontend framework, a hosting provider, a preview setup, a localization layer if you need it, an A/B testing tool, analytics - and someone to keep all the API connections current as each service updates. What starts as a lean stack tends to sprawl.

Cost is less predictable than it looks. Many headless CMS platforms price by content calls, team seats, or locales. Hosting is separate. Preview environments are separate. The total cost of the stack, across services, often lands higher than a comparable all-in-one solution.

None of this makes headless the wrong answer. It makes it a choice with real tradeoffs that should be weighed honestly, not just against the theoretical benefits.

What the alternatives actually offer

The comparison isn't headless versus "not headless." It's about matching the tool to the actual requirements.

WordPress with ACF (Advanced Custom Fields) is one of the most capable setups for teams that need genuine content flexibility and don't want to be locked into a vendor's content model. It's not glamorous, but it's deeply extensible, has a massive plugin ecosystem, and keeps non-technical editors productive. The tradeoffs are real, performance requires active management, security needs attention, and the codebase can get messy without discipline, but for the right team and the right site, nothing is more flexible.

Visual CMS platforms (Webflow is the one we work with most, but others exist in this space) sit in a middle ground that makes a lot of sense for marketing sites. Editors work directly on the page, not inside abstract field structures. Developers still control the underlying structure and can extend it. Publishing is immediate. The constraint is that you're working within the platform's model, which may not fit every requirement - but for the vast majority of B2B marketing sites, it does.

A hybrid approach can also make sense: headless for specific high-complexity surfaces (like a documentation system or a product interface), combined with a simpler solution for the marketing site. Not every part of your web presence needs to be on the same architecture.

The questions we actually ask

Before recommending anything, we try to understand the real constraints:

What are all the surfaces this content needs to reach? If the answer is genuinely "multiple platforms simultaneously," headless becomes much more compelling. If the answer is "a website," that's important to acknowledge.

Who publishes content, and how often? If marketers are publishing campaigns, launching pages, and running SEO experiments on a weekly cadence, they need tools that don't create a ticket queue.

What's the team's actual capacity for infrastructure? A headless stack done well requires someone who can maintain it. Deployment pipelines, preview environments, API versioning - these don't run themselves. If that capacity doesn't exist in-house, the ongoing maintenance gets expensive quickly.

How often does the site's structure change versus its content? A site that changes structure frequently (new page types, new section layouts) will feel the pain of headless more acutely. A site that changes content frequently but has a stable structure is actually a better candidate.

What's the real timeline for content publishing? If campaigns need to go live in hours and no developer should be in the critical path, that changes the calculus significantly.

Our honest summary

Headless CMS is the right tool for specific problems. If you're building for genuine omnichannel distribution, if your team is developer-led, and if you have the infrastructure capacity to maintain it properly - it's worth serious consideration.

For most B2B marketing sites, the pitch is often better than the reality. The developer experience improves. The marketing team's autonomy often suffers. The stack gets more complex than it needed to be.

The better question isn't "should we use headless?" It's "what does our team actually need from a CMS, and which tool serves those needs without creating new problems?"

That's a more boring question. But it tends to lead to better answers.

Want to talk through what makes sense for your site? We've been down most of these roads - we're happy to share what we've seen. Talk to us.