"Headless" has drifted into marketing-speak territory, used often enough as a synonym for "modern" that the actual architectural meaning gets lost. It's worth being precise about what the word means and what it costs, because the decision to go headless is a real trade-off, not a free upgrade.
The actual definition
Headless means the system that manages content or commerce data (a CMS, a commerce engine, or both) exposes that data only through an API, with no templating or page-rendering logic living inside it. The frontend, a website, a mobile app, a kiosk, whatever consumes that API, is built and deployed entirely separately. The backend doesn't know or care what's rendering its data; it just serves it.
What it actually buys you
Frontend freedom: build the storefront or site in whatever framework serves the product best, not whatever the platform's templating system supports. Multi-channel reach: the same backend can power a website, a mobile app, and a kiosk display from one API, instead of maintaining separate content or product data per channel. And a cleaner upgrade path: the frontend and backend can be replaced or rebuilt independently, since neither is tangled into the other's deployment.
What it actually costs
More moving parts, full stop. A coupled platform is one deployment, one system to monitor, one place logic lives. Headless is at least two systems, a backend and a frontend, each deployed and monitored separately, connected by an API contract that both sides need to agree on and keep in sync. That's real engineering overhead, and it's worth it exactly when the benefits above actually apply to your situation, not as a default "headless is more modern" upgrade.
Trying to decide if headless actually fits your situation?
Tell us how many frontends or channels you actually need to serve, and what your current platform is straining against. We'll tell you honestly whether headless solves a real problem for you.
Talk to an engineer →When headless is clearly the right call
A team building for more than one channel from shared content or product data, a team whose frontend needs genuinely can't be expressed inside a platform's own templating or page-builder system, or a team hitting a commerce platform's extension ceiling on logic that matters to the business, all have a real case for headless. The two-teams, two-repos coordination model that comes with it, covered in more depth in how two teams on separate repos stayed in sync, is a real cost worth planning for deliberately, not discovering mid-build.
When it's overkill
One frontend, no near-term plan for a second channel, and a platform's built-in templating or page-builder genuinely serving the team's actual needs: that's a team for whom headless adds real overhead to solve a problem that doesn't exist yet. A coupled platform, kept simple, is usually the better call in that situation, at least until a second channel or a real frontend-flexibility need actually shows up.
The rule
Treat "headless" as an architectural trade-off with a real cost, not a synonym for better. Ask whether you actually need multi-channel reach or frontend freedom a coupled platform can't give you, honestly, before taking on the extra systems and coordination headless requires. For what owning that architecture actually means in practice, see why headless commerce ownership actually matters. We build headless architectures, and help teams decide when not to, under headless commerce and headless CMS engagements.