The headless CMS conversation has matured considerably since 2020. Back then the pitch was simple: decouple your frontend from your backend and unlock infinite flexibility. The reality proved more nuanced. We've now built and maintained enough headless projects to have strong opinions about when the architecture earns its complexity cost.
The genuine advantages
Performance is the clearest win. A Next.js or Astro frontend with static generation and edge CDN delivery consistently outperforms a traditional server-rendered CMS on Core Web Vitals. For content-heavy sites where SEO is the primary acquisition channel, this matters directly to revenue.
Frontend developer experience improves dramatically. React or Vue developers work in their natural environment with the component model they know. Design system integration is cleaner. Visual regression testing is simpler. The feedback loop is faster.
Multi-channel delivery is genuinely easier. If you're delivering content to a website, a mobile app, and a kiosk system, a headless CMS with a well-designed content model is the right tool. Maintaining three separate traditional CMS instances would be worse in every dimension.
The real costs that don't make it into demos
Preview is hard. Getting editors to see how their content will look before publishing requires a dedicated preview environment, token-based authentication, and careful cache invalidation logic. This is solvable, but it's engineering work that adds nothing to user-facing features.
Authentication is your problem now. Traditional CMS platforms handle login, sessions, CSRF protection, and user roles. In a headless setup, your frontend application is responsible for all of this. You'll implement it with an auth service like Auth0 or NextAuth, which works fine, but it's an additional dependency and attack surface.
Editorial workflows get complicated. Drupal's content moderation, revision history, translation management, and scheduled publishing all exist within the CMS. If editors need these features reflected in real-time in a separate frontend application, you're building integration logic that doesn't exist out of the box.
The projects where we'd recommend headless
- High-traffic editorial sites where Core Web Vitals directly affect SEO rankings
- Multi-channel content delivery (web + mobile app + third-party integrations)
- Teams with dedicated frontend engineers who want to work in a modern JS environment
- Projects with complex, custom UI interactions that benefit from client-side rendering
The projects where we'd recommend against it
- Small to medium sites where the editorial team is the primary technical stakeholder
- Projects with tight timelines and budgets — headless adds 20-40% to development time
- Sites where the content model changes frequently — schema changes cascade through more systems
- Teams without frontend expertise who would be inheriting the codebase
The middle ground: Progressive decoupling
Drupal has supported progressively decoupled architecture since version 8. You keep the traditional CMS for rendering most pages, but specific interactive components — a complex search interface, a booking system, a real-time dashboard — are built as standalone React applications embedded in the page. You get the interactivity where you need it without paying the full headless tax everywhere.
For many projects this is the right answer. It's not as architecturally elegant as full headless, but elegance that ships late and costs more isn't actually elegant.
