We build headless systems for a living, which makes it tempting to recommend one for every project. We don't, because the honest answer is that a traditional, tightly-coupled CMS is the better choice for a real share of the businesses that ask us about this.
When a traditional CMS is genuinely the right call
If a site is mostly informational, updated by one or two people, and doesn't need a bespoke frontend experience, the operational simplicity of a single system usually outweighs whatever flexibility a headless split would offer. Two systems to host, secure, and keep in sync is a real ongoing cost — one that only pays for itself once the frontend actually needs to do something a traditional theme can't.
When headless earns its complexity
The calculation flips once a business needs the same content to reach more than one surface — a website and a mobile app, or multiple regional sites sharing one product catalog — or needs frontend performance and interaction design that a page-builder plugin architecture can't deliver without fighting it constantly. That's also when a dedicated experience layer, rather than a theme, becomes worth the coordination overhead we described in our post on why we went headless ourselves.
The question we actually lead with
Before anything else, we ask who's going to be editing content day-to-day, and what they need to be able to do without calling a developer. An architecture that's technically elegant but leaves an editorial team unable to reorder a homepage section themselves has solved the wrong problem.
