Headless CMS isn't always the answer
The "headless everything" trend cost more projects than it saved this year. A short reality check.
Headless CMS solves a real problem: serving the same content to a website, an app, and an internal dashboard from one place. Every demo focuses on that scenario.
Most projects are not that scenario. Most projects have one website and one team that updates it. For those, headless adds a deploy step, a build cache, an extra service to monitor, and a learning curve no client signed up for.
When headless is right
You have multiple consumers (web + native app, multiple brands sharing content, a marketplace of partners pulling your data). You have a content team large enough to train. You have engineers committed to the build pipeline that connects the head to the body.
When it's wrong
Single site. Small team. Content that changes weekly, not hourly. The "future flexibility" we promise ourselves is a tax we pay every release for a benefit that may never arrive.
The default for most clients is still a coupled CMS. Not because it's better - because it's right-sized.