The headless conversation has been the loudest conversation in CMS land for five years now. Every conference talk, every vendor pitch, every agency blog post, every developer LinkedIn thread — all of it tilted in the same direction. Headless is the future. Go headless or get left behind.
The signal-to-noise ratio on this has gotten bad enough that we are going to write the opposite post. Here are the projects where headless is the wrong answer in 2025, the reasons, and the decision tree we run instead of the default ‘yes headless.’
What headless costs you
Before the decision tree, the cost. Going headless is not free. The cost lines that show up on every project:
Two stacks to operate. The CMS backend and the front-end framework are separate codebases, separate deploys, separate hosting, separate monitoring. The team has to know both.
The preview workflow is hard. Editors expect to see what their content will look like before publishing. In a monolithic CMS that is built-in. In a headless setup it is custom work — typically 30 to 80 hours per project, and often the first thing that breaks when the front-end framework updates.
Plugin ecosystem fragmentation. Most CMS plugins assume the CMS is rendering the front end. SEO plugins, caching plugins, conversion tracking — half of them either do not work on a headless front end or require custom wiring.
The editor workflow is more constrained. Inline edit. Visual builders. Live edit. None of these work the same way in a headless setup. Editors who are used to a ‘click here, edit live’ workflow have to adjust to a ‘edit in CMS, refresh front end, repeat’ loop.
The build is roughly 50 to 80 percent more expensive. Two stacks costs more than one stack.
When the cost is justified
The conditions where headless earns the cost, which we wrote about in 2021 and still hold:
- Performance budget that a monolithic CMS cannot hit at scale
- Rich interactive front end that benefits from a React or Vue component model
- Large editorial and engineering teams that need to ship on independent cadences
- Multi-channel content delivery (website + mobile app + digital signage from the same content store)
- Enterprise budget that absorbs the engineering overhead without breaking the project economics
If at least one of those conditions is genuinely true, headless is on the table. If none of them are true, the right answer is almost always a monolithic CMS, tuned well, deployed carefully.
The decision tree
The flow we run in discovery, in order:
Question 1: What is the budget?
Below 40,000 dollars: monolithic CMS only. Headless is not a serious option at this budget.
Between 40,000 and 100,000: monolithic by default. Headless only if at least two of the five justification conditions apply.
Above 100,000: headless is on the table. Continue down the tree.
Question 2: What is the team shape?
If the marketing team is small (1-3 people) and the engineering team is external/contracted: monolithic. The operational overhead of two stacks does not pay back at this team size.
If both teams are mid-sized (4-15 people each) and embedded in the company: headless is realistic if the other conditions justify it.
If the team is enterprise scale (15+ people on each side): headless is often the right call simply because the team can absorb the operational complexity.
Question 3: What is the content shape?
If the site is primarily a content marketing engine — blog, case studies, evergreen pages, light dynamic content — a monolithic CMS like WordPress is genuinely the best tool for this. Going headless adds complexity without solving a real problem.
If the site is an interactive web application with content as one input among many — configurators, real-time data displays, personalization layers — headless is more natural.
If the content is multi-channel (web, mobile app, digital signage, voice) — headless wins almost by default. A monolithic CMS does not deliver to non-web channels well.
Question 4: What is the performance ceiling?
If the site can hit its performance targets on a tuned monolithic CMS: no need for headless. WordPress with a clean theme and good hosting hits Lighthouse 90+ on mobile for content-heavy sites.
If the site genuinely cannot hit its performance targets on a monolithic CMS: headless is a justified architectural change. This is rare in practice.
Question 5: What is the in-house technical capacity?
If the in-house team has React experience and an active engineering culture: headless is operationally viable.
If the in-house team is primarily marketing operations with limited engineering: headless is going to be painful. Stay monolithic.
What we end up recommending
The honest distribution from our 2024 discovery calls:
- About 70 percent of projects: monolithic WordPress (or in some cases, a no-code platform like Webflow or Framer)
- About 20 percent: hybrid — WordPress backend with a custom Next.js or Astro front end for specific high-traffic pages, but most of the site still monolithic
- About 10 percent: full headless, justified by enterprise requirements
The 10 percent is real and the architecture is genuinely the right call for those projects. The 70 percent is also real, and for those projects the headless conversation is a distraction.
The hybrid pattern that works
The most interesting projects in 2024 were the hybrid ones. The pattern: WordPress as the CMS, with the marketing site rendered through PHP templates, but specific high-traffic pages — typically the home page, product pages on an e-commerce site, or the top 20 blog posts by traffic — pre-rendered through Next.js or Astro on a separate hosting tier.
This gets you the performance wins of a pre-rendered front end on the pages that matter most, without the operational overhead of moving the entire site off the monolithic stack. The editor still sees a normal WordPress admin. The marketing team still uses the WordPress plugin ecosystem. The high-traffic pages get the speed they need.
It is not as elegant as a full headless build. It is more practical for the kinds of projects most companies actually have. It is the architecture we now recommend on roughly a fifth of our marketing-site engagements, and the one we expect to see more of through 2025.
The bottom line
Headless is a tool. Like every tool, it has a best-use case and a worst-use case. The industry conversation has been pretending it has no worst-use case for five years. That has resulted in a lot of expensive projects that did not need the architecture they got.
The right question is not ‘should we go headless.’ The right question is ‘what is the simplest stack that meets our requirements for the next three years.’ For most projects, that is not headless. For some projects, it is. The decision tree above is how we separate the two.