Not all Headless CMS are made equal

The section you’re probably looking for is all the way down --- “OK, so what?“. Warning: This is also terribly written as it’s mainly paraphrased from a late-night beer-fueled rant.

Having worked at and with GraphCMS Hygraph for about 3 years, I’m now exploring a different side of the table as a Storyblok user at Lano.

(Add-on disclaimer I guess 😅, as of Dec 2023 I’m back into the Headless CMS space working at DatoCMS)

The fascinating bit to me is that although they’re both leaders on the same G2 grid for Headless CMS with very similar comments, the nuanced differences in their API and capabilities are quite striking.

Throw in the wild mix of other CMS and Headless CMS I got to play around with over those 3 years (Sanity, Strapi, Contentful, Prismic, Dato, Contentstack, WordPress (😶‍🌫️), Ghost, and Webflow), I started to realize that each platform isn’t necessarily “interchangeable” across all use-cases. Some really are highly opinionated and/or suited to a very different type of user and end solution.

⚠️ This is a bit of an opinionated take based on personal experiences, so by no means is it supposed to be a “this is what this CMS is for” directive.

What is a Headless CMS?

Since I’m not here to “compete for rankings” on the whole “What is a Headless CMS?” keyword (Contentful, Storyblok, and Sanity win here, and do a better job at diving deep into the topic), I can be a bit blunt and go off on a tangent.

What is a Headless CMS? Illustrated. Courtesy of Strapi.

If you’re thinking in websites, and more specifically WordPress websites --- you have the backend (that clunky vortex of PHP programming over a MySQL database), the “CMS” (the authoring layer, the admin interface, the GUI, whatever you call it, that /wp-admin thing), and the frontend (your website, web page, landing page, etc. --- in this case, the “head”).

That worked great for a while, but people soon started to realize a bunch of realizations:

• The infrastructure was too damn opinionated. If you’re using WordPress, you HAVE to know PHP, work in their plugin ecosystem, manage multiple websites, stick with a restrictive ecosystem of technologies, etc.

• ”Omnichannel” was beginning to become a buzzword, and if people had to create content for everything from TVs and watches to dishwashers and ice cream machines, WordPress-ey website builders weren’t going to cut it, and having one CMS per platform/frontend wasn’t sustainable.

• Overheads like training, security, maintenance, hosting, etc. didn’t have an “industry standard”, so living on a vendor’s whims led to expensive lock-ins where teams weren’t really in control of their infrastructure.

• You really needed to hire and train specialists (think PHP developer, Java Developer, etc.) and not just have an army of all-star full-stack devs who were working with something as flexible and extendible as JavaScript (also all the “cool” devs want to play with Svelte, Next.js, Express, Gatsby, Laravel, Pengu1n, Ember, etc., not with PHP --- try and figure out which one of those frameworks is made up 😬)

• If one plugin had to be updated or one security patch for one functionality had to be implemented, the entire infrastructure would likely have to go down (think self-hosted), and since many enterprises preferred self-hosted monoliths, scalability at peak times like Black Friday meant ridiculous price tags to maintain an infrastructure that could handle the load (again, think self-hosted) rather than just being a cloud-native application that could scale at peak times when needed.

Long story short, people figured out they needed to decouple this CMS direction to focus on building better digital experiences, and so chopped off the head, to be able to focus on having a relatively unopinionated backend to store all their content in a structured format, build out a schema, and then query for all that content to any frontend using a language or framework they preferred.

That decoupling is simplified, courtesy of Sanity.

Think hosted GraphQL API as a backend/database, and a Next.js application rendering that data on a website, SaaS product, dishwasher, wherever. A Headless CMS completely defies that tightly coupled logic by fragmenting the flow and decoupling the front end from the back end, keeping its focus on the content creation and storage, with little to no control over the front end rendition.

What a Headless CMS is not

A Headless CMS is not a website builder.

End of Section.

All though in many cases it may not even really be a “CMS” at all. It’s more accurately a content database, or a content backend, or a content API, or a hosted backend, or backend as a service, but not necessarily a “Content Management System” since they can do much more than fulfill a CMS use case.

Focusing on the spectrum of capabilities

Now, we know that Headless CMS can build websites. In fact, they do them really well according to this, this, this, and many, many more.

But, why then, do several CMS try to pitch themselves as “more than a CMS”? Contentful goes with “Content Platform”, Hygraph takes “Federated Content Platform”, and Sanity tries to push a “Content Lake”, to share a few examples.

Why the need for this differentiation? Isn’t Headless CMS a commodity by now that everyone knows which one to grab without having to dive into yet another layer of buzzword bingo?

Turns out, there’s quite a bit of nuance to this.

Sanity’s lake direction makes them more of a database, dealing with structured and unstructured content to be rendered to any application whether or not content operations exist within a use case.

Hygraph’s Federation takes the concept of GraphQL federation and runs it on the content layer. This allows to bring in content from external remote sources, enrich them with content from Hygraph (or not), and deliver them via a single GraphQL API, making it a powerful “API integration” play (think Mulesoft or Kong), for use-cases where it makes sense to treat the CMS as the “single source of truth” or “single point of failure”, like a streaming application or a Yahoo! Finance like dashboard.

Contentful’s “Content Platform” pushes for an evolution of the CMS by focusing on orchestrating multiple content operations across tools, APIs, and services, to aggregate content from other platforms (using their App framework) into Contentful, again trying to position the CMS as the single source of truth.

This sounds similar to Federation, but the key differentiator here is Hygraph consolidates (external sources are the source of truth for their data, channeling via Hygraph ensuring data integrity), whereas Contentful aggregates (by writing the external data into Contentful before it’s queried for), which could potentially lead to stale data depending on the frequency of data changing.

In fact, if I had to take a shot, I’d say the only true “CMS” from a classical marketing focus from all the options in the headless arena would be Storyblok because of how they integrate a frontend editor with a content API --- in most cases, editors don’t even know they’re working with a Headless CMS. Nor do they care to be honest (although the whole “Headless CMS for marketers” argument is something I’ll get into another time).

OK, so what?

Going further on my understanding of the capabilities of “Headless CMS” today, it’s clearer to see why some outcompete others on very specific use cases. When working at Hygraph, I started to get really involved in understanding more about vendor selection when having discussions with other MACH vendors, seeing which events and conferences other vendors were present at, and when observing what kinds of case studies each vendor was promoting (as well as some insights from our own sales discussions).

Some patterns began to become quite apparent.

When marketers were leading the discussion, or when heavy editor-focused use cases were on the table (think blogs, magazines, lifestyle brands, etc.), Storyblok, Contentful, and Contentstack were almost always mentioned.

When Product teams were leading the discussions on application use cases (think eCommerce, apps, PWAs, programmatic editorial content), Hygraph and Sanity would come up just as often as Contentful.

When the budget was the prime driver or when the use cases weren’t as ambitious, I’d notice Storyblok mentioned often alongside Prismic and DatoCMS.

But, interestingly, when data-heavy product use cases came by, led by Architects, Product, or Senior Engineering (think streaming applications, intranets with RTC, platforms with deeply granular access control, eCommerce platforms with data-rich feeds across markets, gaming platforms with heavy metadata needs, SaaS platforms with multiple APIs in need of stitching etc.), Hygraph and Sanity were most commonly mentioned, however, wildly uncategorical names like Hasura, Apollo, Supabase, and Mulesoft also made it to the table.

This convinced me that Headless CMS is in fact, more than a CMS, and labeling them as such is doing them a disservice given how commoditized and stereotyped the term “CMS” has become to MarTech.

Some are an API-first CMS. Some are primarily hosted backends with a UI for content operations because Backend-as-a-Service doesn’t always make for the sexiest segment, and being put head to head with the Herokus and the Amplifys is a daunting prospect for any tool. Some are robust databases moonlighting as a CMS because it’s easier to gain traction in that segment when you’re not OSS without only billing on API hits.

Based on this, I’ve formed a highly subjective opinion on where today’s leaders in the “Headless CMS” category actually fall, in between being a CMS and/or a Backend-as-a-Service.

My (very subjective) opinion of where each headless CMS sits on being a CMS v. being a hosted backend/database that is misunderstood. Pricing is based on my observations/research of their full feature set without enterprise SLAs or support. This may or may not be accurately represented amongst various use cases.

My spectrum of where vendors sit on the “is a marketing CMS” to “is not a marketing CMS”. At this stage I consider Contentful as the sweet spot sitting in between being equally useful to marketers and to developers for a wide variety of use cases (although with Publish and Launch, one could argue they’re creeping more into AEM territory given the feature set and pricetag)

But even so, if Headless CMS is eating into lots of places where you’d reach for a traditional database, this is the playground they’re playing in. Even if some provide better APIs than the other, or give the ability to manage extremely complex schemas, they all chose to be a CMS (whatever the market interpretation of that term is now), and made their beds.

The scenario this creates is something I’m quite keen on seeing unfold. With some clearly focused on the API and the developer use cases in contrast to the “CMS” narrative on building websites or apps, there’s going to be an interesting move in category creation over the next few years. Some will try to eat WordPress’s lunch as they build rich FEaaS feature sets, some will overlap into the Hasuras as they focus on extensibility, and some with creep into Supabase territory as they focus on the database capabilities.