Every few years, a technology shift in web development starts generating a lot of noise. Right now, that shift is headless CMS. Agency pitches are full of it. Developer job postings mention it constantly. And if you're a business owner trying to figure out what your next website should look like, you've probably heard the term without getting a straight explanation of what it actually means or whether you should care.
We've been building websites for over 25 years, and we've deployed headless CMS setups for clients who genuinely needed them. We've also talked clients out of headless when it would have been the wrong call. This article is the honest version of that conversation.
What "Headless" Actually Means
A traditional CMS like WordPress bundles two things together: the place where you manage your content (the back end) and the way that content gets displayed to visitors (the front end). When you write a blog post in WordPress, the same system that stores your words also generates the HTML page your visitors see. The content and the presentation are one system.
A headless CMS splits those two apart.
The "head" in this metaphor is the front end — the visible website. Removing the head means the CMS only handles content storage and delivery through an API. It doesn't generate web pages at all. Instead, a separate front-end application — built with something like Next.js, Astro, or even a mobile app — requests content from the CMS through that API and handles all the display logic on its own.
Think of it like a kitchen and a dining room. A traditional CMS is a restaurant where the kitchen and the dining room are permanently connected by a single door. The food goes one direction, served one way. A headless CMS is a commercial kitchen that serves food through a pickup window. Delivery drivers, dine-in waitstaff, food trucks, catering vans — anyone can pick up from that window and serve the food however they want.
The headless CMS market has been growing at roughly 22% per year, and the global market is projected to grow from about $1 billion USD in 2025 to over $7 billion by 2035, according to Future Market Insights. But market growth alone doesn't tell you whether it's the right choice for your specific business.
When Headless Makes Sense
Headless architecture solves real problems. But they're specific problems, not universal ones. Here's where we recommend it.
You're publishing content to more than one platform. If the same product descriptions need to appear on your website, your mobile app, a digital kiosk in your retail location, and a partner's marketplace, a headless CMS lets you author that content once and deliver it everywhere through APIs. A traditional CMS would require you to copy-paste or build brittle integrations between each platform. For multi-channel businesses, this alone justifies the investment.
Your front-end team wants freedom. Traditional CMS platforms constrain what your developers can build. WordPress themes have a specific structure. Shopify has its Liquid templating language. A headless setup lets your front-end team use whatever tools make the most sense — React, Vue, Svelte, Astro — without being locked into the CMS's opinions about how pages should render. If you're investing in a custom-built site with a specific performance or UX goal, this freedom matters.
Performance is a competitive advantage for you. When the CMS isn't generating pages on the fly, you can pre-build your entire site as static HTML and serve it from a CDN. The difference is measurable. Smashing Magazine reported an 85% improvement in page load speed after moving to a static architecture. Sites served from edge CDNs consistently show lower Time to First Byte, which directly affects your Core Web Vitals scores and search rankings. For e-commerce sites where a one-second delay can reduce conversions by 7%, that gap between 1.2 seconds and 3.8 seconds isn't academic.
You need to scale without worrying about server crashes. Static files on a CDN don't crash under traffic spikes the way a database-backed WordPress install can. If your site goes viral, gets featured on a news outlet, or runs a product launch campaign, a headless-plus-static setup handles the load without emergency server upgrades. The architecture is inherently more resilient because there's no server-side computation happening for each visitor.
Your content structure is unusual. A headless CMS lets you define your own content models from scratch. If you're a real estate company that needs listings with 40 structured fields, or a SaaS company with complex documentation, or a publisher with multiple content types that relate to each other in non-standard ways, a headless CMS gives you the flexibility to model that data properly instead of shoehorning it into a blog-post-shaped database.
When Headless Doesn't Make Sense
We talk plenty of clients out of headless, too. Here's where it creates more problems than it solves.
You have a small team and no developer on staff. A headless CMS by itself has no front end. None. There's no "install and go" the way there is with WordPress or Squarespace. You need a developer to build the front end, connect it to the CMS, and maintain that connection over time. If your plan is to hand the site off to a marketing coordinator who updates it weekly, a headless setup creates a dependency on technical talent that a traditional CMS doesn't require.
This is the single biggest reason we steer small businesses away from headless. The ongoing cost of that developer dependency — whether it's an in-house hire or an agency retainer — can dwarf whatever performance or flexibility gains you'd get. As TechTarget's analysis puts it, if your organisation lacks resources for IT support and wants an environment that lets people customise options on their own, headless likely isn't the right fit.
You're building a five-to-fifteen-page brochure site. A local service business in Calgary with a homepage, an about page, a services page, a contact page, and maybe a blog? WordPress with a well-built custom theme will do everything you need. Faster to build, cheaper to maintain, easier for you to manage. Going headless for this use case is like renting a commercial kitchen to make toast.
You don't have the budget for the front-end build. Headless CMS pricing itself can be reasonable. Sanity's free tier gives you 20 users and two datasets. Strapi is open-source and free to self-host. Contentful has a free plan with one million API calls per month. But the CMS cost is the smaller number. The real expense is the front-end application that consumes the API. A Next.js or Astro front end built from scratch takes 40-120 hours of development time, depending on complexity. At typical agency rates, that's $6,000 to $18,000 before you've written a single word of content. Compare that to a custom WordPress theme at $4,000 to $10,000 that includes the entire stack, content management and front end together.
Your editors need a visual preview. Most headless CMS platforms don't show you what the page looks like while you're editing. You're working in a structured form — filling in fields, writing in rich text editors, selecting images — but there's no "preview" button that shows the finished page. Some platforms (Sanity's Presentation tool, Contentful's Live Preview) have added this, but it requires additional development setup. If your team relies heavily on seeing the page as they build it, the editing experience in a headless CMS can feel like a step backwards from WordPress or even Squarespace.
The question isn't whether headless CMS is better or worse. It's whether the problems it solves are actually your problems.
The Real Options and What They Cost
If you're considering headless, here's an honest look at the major platforms we've worked with and recommend to clients.
Strapi is open-source and self-hosted, which means you own the code and your data never leaves your server. Strapi 5 runs on Node.js with PostgreSQL, MySQL, or SQLite. The software itself is free. Hosting typically runs $10-40/month on a VPS, plus your team's time managing the server. Strapi Cloud now offers a free plan for smaller projects. We reach for Strapi when clients want full control over their infrastructure and have a developer who can maintain it.
Sanity is a hosted platform with a generous free tier (20 users, usage-based billing above that). Its editing experience through Sanity Studio is the most customisable of any headless CMS we've used — your editors can have an interface tailored to exactly how they work. The Growth plan starts at $15 per user per month. We recommend Sanity when the editorial experience needs to be as polished as the public-facing site.
Payload is the newer entrant worth watching. It's open-source, built on TypeScript, and manages to be both developer-friendly and editor-friendly. Payload 3.0 runs on top of Next.js, which means you can deploy your CMS and your front end as a single application. That simplifies the architecture significantly compared to running two separate systems. We've been using Payload for projects where the client wants the flexibility of headless without the overhead of managing separate deployments.
Contentful sits at the enterprise end. The free tier works for experimentation, but production use on the Lite plan starts at $300/month, and enterprise contracts typically run $37,000-$60,000 per year. Contentful makes sense for large organisations with multiple content teams, complex approval workflows, and budgets to match. For most small and mid-size Calgary businesses, it's overkill.
Decision checklist: Should you go headless?
Answer yes or no to each:
- Do you deliver content to more than one platform (web + app, or web + kiosk, or web + partner feed)?
- Do you have a developer or agency relationship that can build and maintain a custom front end?
- Is your annual web budget above $15,000 (build + ongoing)?
- Are your content models more complex than pages-and-posts?
- Is sub-2-second page load time a measured business requirement?
Scored 4-5 yes: Headless is likely the right architecture for you. Talk to a developer who works with both traditional and headless systems to plan the migration.
Scored 2-3 yes: You might benefit from a hybrid approach — WordPress with a headless front end, or a CMS like Payload that blurs the line between traditional and headless.
Scored 0-1 yes: A traditional CMS will serve you well. Don't let anyone sell you architecture you don't need. The money is better spent on content, design, or fixing performance issues with what you already have.
The Hybrid Path (and Why We Often Recommend It)
The conversation doesn't have to be all-or-nothing. Some of the best setups we've built recently are hybrids.
WordPress can operate as a headless CMS. You manage content in the familiar WordPress admin, but instead of using a WordPress theme for the front end, you pull content through the WordPress REST API (or WPGraphQL) into a Next.js or Astro front end. Your editors keep the interface they already know. Your developers get the performance and flexibility of a modern front-end stack. You avoid the page builder bloat that degrades WordPress performance while keeping the parts of WordPress that actually work well — its content editor, its plugin system for back-end functionality, its massive community.
This hybrid approach works particularly well for businesses that already have a WordPress site with years of content. Instead of migrating everything to a new CMS (a painful process we know well from helping clients with site migrations), you keep WordPress as the content store and replace only the front end.
The 2025 HTTP Archive Web Almanac measured the median CMS page at 2.67MB on desktop, with JavaScript alone accounting for 697KB on a typical homepage. Much of that weight comes from theme and plugin bloat in traditional setups. A headless front end built with Astro can ship that same content in under 200KB total, because Astro renders everything to static HTML and only sends JavaScript to the browser when a specific component genuinely requires interactivity.
That performance gap is where headless architecture earns its keep — not as a buzzword, but as a measurable reduction in page weight, render time, and infrastructure cost. Whether you get there through a fully headless setup, a hybrid approach, or a well-built traditional site depends entirely on your business, your team, and your budget.
The right answer is the one that matches your actual situation, not the one that sounds most impressive in a proposal.
Sources
- Future Market Insights — Headless CMS Software Market Size & Trends 2025-2035
- Storyblok — Headless vs. Monolithic: CMS Usage Statistics & Trends 2025
- Sanity — Headless CMS vs Traditional CMS
- Strapi — Traditional vs Headless CMS: A Comparison
- Strapi — Exploring Strapi's Architecture
- TechTarget — Know When to Use a Headless CMS and When It's Not Worth It
- HTTP Archive — CMS Chapter, 2025 Web Almanac
- Contentful — Headless CMS Explained
- Sanity — Pricing Plans
- CrafterCMS — Hidden Costs of a Pure Headless CMS