Start with the part that doesn't flatter us. If you run a five-page brochure site with one template and no second channel, a traditional CMS wins. It gets a page live faster, with less engineering, and your editors get a live preview for free. Headless makes you build that preview back yourself.
Now the part vendors blur.
Headless architecture means the CMS ships no render code at all. A decoupled CMS still ships a frontend, just split into its own app. A hybrid CMS is a traditional CMS with a content API bolted on. Draftbase is headless in the strict sense: a dashboard, a delivery API, and nothing in between pretending to be a frontend.
"Headless" sells better than "decoupled", so plenty of decoupled tools market themselves as headless anyway. One test settles it. Open the docs and look for a page builder or a theme system. Found one? Not headless.
Run it against three vendors who all say headless on the homepage:
- Drag-and-drop block builder. That's hybrid.
- A "starter frontend" repo to clone. That's decoupled. The vendor still owns an opinion about rendering.
- Dashboard, schema builder, API reference, no render code. That one's headless.
None of the three is a wrong pick. But a team that picks the first one expecting frontend freedom inherits a template system it never budgeted for.
The scale is smaller than the discourse suggests, too. Less than 12% of live sites run headless, against 68% on some form of CMS at all (Storyblok). Adoption grew 47% in 2025, mostly from teams leaving Adobe AEM, Sitecore, and Drupal. That's a flight pattern, not a conversion.
The full breakdown, including the concrete cost of going headless, is on the canonical post: Headless Architecture Explained.
All jokes aside, we're a CMS, we know. Draftbase stores content as typed fields and hands MDX straight to next-mdx-remote. Hobby is free, Startup is $49/mo, and the number is on the pricing page rather than behind a call. More arguing about labels over at r/draftbase_cms.
