Headless means your CMS stops rendering pages and becomes a content API; a separate front-end — usually Next.js or similar — does the rendering. We've built both directions for years: headless Drupal and WordPress feeding React front-ends, and firmly coupled builds we'd defend today. The pattern in what worked is consistent.
What headless actually buys
What it costs — the part the pitch skips
You now run two systems. Two deploy pipelines, two things that can be down, and an API contract between them that every content-model change must cross. Preview — editors seeing a draft exactly as it will render — is free in a coupled CMS and a real engineering project in a headless one. Same for menus, redirects, layout control, and that page-builder autonomy your marketing team quietly loves. None of it is impossible; all of it is now your engineers' job.
Going headless moves work from the CMS vendor's roadmap to your payroll. Sometimes that trade is brilliant. It is never free.
Our rule of thumb
Go headless when at least two of these are true: content serves multiple channels; you have (or are hiring) a dedicated front-end team; page performance is a revenue lever you can quantify; or the front-end will be redesigned more often than the content model. Stay coupled when a marketing team runs the site day-to-day with limited engineering support — a well-built Drupal or WordPress site with modern caching is faster than its reputation and dramatically cheaper to operate.
The middle path nobody markets
Progressive decoupling: the CMS keeps rendering most pages, while the genuinely interactive surfaces — a configurator, a dashboard, search — mount as embedded React apps fed by the same API. You keep editorial autonomy and preview, gain modern interactivity where it matters, and defer the two-system tax until multi-channel demand actually arrives. It's the least quotable architecture and, for mid-size organisations, the one we recommend most.