Points of Differentiation in Headless CMS

When was the last time a project failed on selection of the database server?

Have you ever heard, “This project would have worked if we had used Postgres rather than MySQL.” Or SQL Server rather than Firebird. Etc.

You don’t hear this because we just don’t expect much from database servers. They have a wide range of functionality, but what do we use? Tables, columns, keys, and maybe stored procs or views? (Truth: I don’t remember the last time I wrote a stored proc. I’ve actually written a manifesto against them.)

When was the last time you used a feature of a database server that isn’t available in a competing product? Not something that’s just done differently, but a feature that literally doesn’t exist in anything other than the database server you selected for your project?

The way we use them, database servers are largely fungible, which means:

Something that is exchangeable or substitutable.

Assuming we can connect, we can usually swap one for another. This is why database abstraction layers exist.

Our usage patterns of database servers are very narrow. We just don’t ask a lot from them, generally. If you’re a Windows developer, you’re probably always gonna use SQL Server because it’s just fine, and you wouldn’t think to question that.

When usage patterns are narrow, software is easily substituted. As usage patterns get wider – as you start doing more interesting, varied, and complex things with the software – it gets harder to substitute because you start to wiggle your way into places that only a subset of the products support.

Now, consider headless CMS.

Right now, the usage patterns for headless are narrow. These products are still young, so mostly they’re being used for remote management and access to a structured repository of content…full stop. If you can model your content, manage it, and access it over REST, you’re good. We’re just not asking for much right now.

This is one of the selling points of headless: don’t buy a bunch of stuff you don’t need. Indeed, this was the original point. The value prop – implicitly or explicitly – is, “We’re stripped down to the core essentials.”

Given this, how are headless vendors competing? How are the individual vendors setting themselves apart from each other to avoid fungibility? How are they proclaiming “This is the thing we offer that no one else does that will help with your project!”

In short: why should a customer pick one headless CMS over another?

Here are some thoughts.

Content Modeling

The most basic thing a CMS needs to do is to allow you to accurately represent a logical domain of content in a structured, reusable, and manageable way. This means creating content types, properties, and relationships to describe what your content is and how it should be managed.

There are three sub-disciplines here:

• Discrete Modeling: This is describing a content object unto itself, meaning the properties that are specific to that content object and wholly contained with it. “Title,” for example.

• Relational Modeling: This is describing how a content object relates to other content objects. For instance, our “Article” type should have a property called “Author” which is actually a link over to a separate content object of the “Author” type (trivia: I stumbled on the phrase “relational content modeling” 12 years ago.)

• Organizational Modeling: This is the grouping of content into aggregations (I’ve called these “assemblies” in the past). A content tree is a core type of content organization (which I’ve called “geographies” in the past). So are things like categories, taxonomies, lists, and menus. Given sufficiently advanced relational modeling, you can usually rig up organizational models (you can create a content type for “Taxonomy Term,” for example), but some systems have specific subsystems for common organizational schemes.

Most headless systems are doing well on the first two items here – discrete and relational modeling. You can create different content types, and specify reference properties to link them together.

However, there’s still a dearth of organizational modeling. Some systems have categorization and tagging, but it’s sporadic. I do know of one vendor with a fabulously visual graph database, where every entity is related to every other entity – and everything in the installation is an entity, from the folder the content lives in, the editor who created it, each individual tag assigned to it, etc.

Weirdly, content trees are conspicuously absent. “That’s web-centric,” one vendor told me – a point with which I strenuously disagree. I feel like parent-child relationships are a natural way to model all sorts of content, but the tide of headless vendors is clearly against me on this.

UI Usability

The editorial UI is what editors interact with to create content. This includes the interfaces they navigate through, as well the the editing widgets themselves. Some of this piggy backs on the content model, since widget selection very much depends on the underlying datatype of the property (a date-picker for “Published Date”, for example).

Headless systems benefit greatly from a coincident of their timing – they were born into the Era of the Big Client. Most all headless systems have come into being after mature JavaScript frameworks have taken over page rendering.

And, since they allow remote access to content, many editorial UIs are simply Single Page Applications (SPAs) making REST calls using the same querying API available to their customers. Indeed, a headless CMS that used more traditional HTML via server-side rendering would seem highly out of place.

And, given their age and purposefully-limited featureset, headless vendors don’t have legacy UI elements to support, and their interfaces tend to be very clean and content-centered (indeed, what else is there to do?).

Editorial Tools

These are the tools that editors use to actually manage content, apart from the actual UI. Things like:

• Workflow

• Approvals

• Permissions

• Preview

• Versioning

• Version Control

• Publication Labels

• Archival (ill-defined as that is)

These are the…boring (?) tools that editors use to get content created, edited, managed, published, unpublished, archived, and deleted. These tools are unglamorous, but necessary.

While grouped under what I’d call “repository services,” these tools are often the last in line to get developed. In many cases, their absence just doesn’t stick out enough during demos, because few vendors proactively demo them (how exciting is it to watch something get archived?), and many users take them for granted so they don’t think to ask for them (“Of course it allows for approvals! What CMS wouldn’t…?”).

These are tools that get developed later in a CMS’s lifetime, when the user base has gotten large enough that enough customers are asking for them. In a new market, when vendors are scrambling to show of exciting, highly-visible stuff, these tools fall through the cracks.

Performance Scalability

A big selling point in headless is its ability to serve a massive throughput of data – so-called “hard” scalability, or raw requests-per-second. Most headless systems do this by publishing into a Content Delivery Network (CDN). So, when you request content from your headless CMS, you’re actually requesting content from Cloudfront or Fastly or something.

The “cache-ability” of your content will differ greatly depending on architecture and level of personalization. Additionally, you can implement your own caching schemes – my book website, for example, has made just six requests to its headless CMS in the last 15 days, as it caches everything at the web server (not a typo: six).

But there are situations – mobile, for instance, when you might literally have millions of clients in people’s pockets, each making live requests all the time – you need massive scalability.

Dev Ops Integration and Scalability

The headless market is still decidedly developer-centric. As such, many headless systems are building deep integration into dev ops tools.

For instance, having to create your content model from a UI is not something a developer usually wants to see. They want to define a content model in a file (I’ve said before that files are “the currency of web development”), check it into source control, and have content model changes happen directly from a branch. Additionally, they want to be able to clone environments, change their models, and generate diff files to propagate to other environments. They want to be able to manage everything from a command line, and have hooks to continuous integration platforms, unit testing suites, and other deployment workflows.

For some developers, even logging into the UI would be considered a failure. They want to manage their headless CMS like just another one of the hundreds of database instances they have in their organization. They want it to bend to their process, not the other way around.

Many headless vendors are seeking to become “content infrastructure.” The last thing a vendor wants is to become a speed bump to a development shop’s process. The goal is to fade into the background like the network itself – something you don’t think about much, but you always know is there and that you’d be helpless without it.

Remote Event Hooks

Headless CMSs are built around their APIs, so the ability to manipulate content remotely is just table stakes. But what’s trickier is event-based programming. Since you can’t program inside a SaaS CMS, when something changes inside the repository, it’s often necessary to notify an external process.

Example: above I mentioned how my book site caches all the content in the web server process, and those rarely ever talks to its headless CMS. However, when something does change, my headless CMS calls a URL on the site and tells it to clear the cache. On the next inbound request, the site retrieves the updated content.

This is commonly called a “webhook” (15 years ago, I came thisclose to naming them…). There have been attempts at standards around this, but, to my knowledge, it’s a wide-open space. Some systems just send an empty HTTP request, while others will actually POST the changed content. Some allow for authentication, some allow for customization of the HTTP request (custom headers and such), etc.

I’d like to add other integration hooks here, but I’m not sure there are many. Since you can’t code logic into a SaaS-based CMS, and the core CRUD API is a given…what else is there? Webhooks are the main conduit by which these systems communicate with the outside world about events occurring within the system.

SDKs, Code, and Query Language Support

Every headless CMS offers some form of remote access and querying, so every headless CMS can “fall back” to REST over HTTP, usually delivering JSON.

The existence of the ability to search the repository via URL-based queries is clearly binary and required, but the actual capabilities are on a spectrum. Most systems offer full-text support, but there are vagaries in the querying models that might make a difference (for example: are relational properties two-way? Given an Article, you can get the Author, but given an Author, can you find all their Articles?).

Some particular subsystem architectures, protocols, and standards are desirable for specific developers and scenarios:

• Authentication schemes like SAML or OAuth

• Query languages like GraphQL

• Security protocols and standards like SOC 1/2, PCI DSS, or FISMA

• Privacy protocols like GDPR

Additionally, some systems have abstraction libraries for specific languages (Software Development Kits, or SDKs), so you can get pre-built code that “wires up” some of the backend stuff and makes querying easier.

Delivery Channel Features

This one might seem weird, because the rejection of “channel awareness” is de rigueur in headless – “We manage content, not pages!” The whole idea is that they don’t do anything in the delivery channel.

However, some vendors are making concessions to common channels – particularly the web – and offering specific features for them. (In fact, I like that name for this phenomenon: “Channel Concessions,” which means, “We’re headless, but we concede that we can do something to help this specific channel, so we’re going to do that.”)

• Some vendors have JavaScript libraries that give “click to edit” functionality in HTML

• At least one vendor is offering a “landing page builder” to allow for the spatial organization of content on a page surface

• Some vendors have preview functionality which will load specific preview URLs in the editorial interface, which allows HTML-based preview

• One vendor has a “Synchronization API,” which allows you to make a query with a date, and effectively say “Give me all the content that has changed since this date.” This is particularly helpful for mobile, when you might need to refresh a local content repository.

• I’ve seen analytics usage tracking, where a channel can callback to the repository to register the view of a piece of content. While this is channel agnostic, the most obvious usage would be web tracking.

It’s going to be interesting to see where this goes. I feel we’re going to increasingly see vendors offering features for specific channels, either in the core or in packaged add-ons that we might implement or “activate” for a project involving that channel. Like those I’ve detailed above, we’ll see tools that only make sense in the web channel, or the mobile channel, or whatever.

Taking this to an extreme conclusion, we might find vendors eventually offering full-blown “website builders” that allow all the same tools as a traditional, coupled CMS…just using their headless system as a repository. At that point, they’ll have basically created an entirely separate product.

(Watch some of the traditional vendors that are starting to offer separate headless functionality – Evoq, Kentico, etc. One day, they may just swap in their headless system as the backend repository for their core CMS, and won’t that be interesting?)

Pricing and Licensing Models

While this criteria is true for any CMS (any software package at all, really), it has some uniqueness around headless CMS, for two reasons –

First, the headless market is dominated by SaaS models. There’s probably no genre of content software more specific to a SaaS licensing model than headless. Almost all systems are subscription, and pricing varies significantly.

Additionally, the axes on which subscription pricing turns are vastly different. Some systems charge by users, some don’t. Others allow a certain volume of content, others are unlimited. Almost all have some limitations around API requests, but some differentiate between retrieval requests serviced by the CDN and requests that query the repository (uncached requests, or update/create/delete requests).

Second, despite the dominance of SaaS, some headless systems can be on-premise. There are a few open-source options, and some commercial systems allow for on-premise installations. While the overwhelming majority of customers simply subscribe, some organizations demand a on-premise system. If so, the list of available options pares down very quickly.

Vendor Reputation and Stability

Like the prior section, this is true of any CMS selection, but it takes on added significance with headless because the market is so young and is tilted towards SaaS, which means the barrier to entry is low.

Right now, new headless CMSs are entering the market every single month. I’ve tried to keep up, but there’s just no way to stay on top of all the new releases.

This is due to the fact that a headless CMS is easier to build than a traditional CMS, because large parts of the traditional CMS featureset have been omitted. There’s no need for templating or response logic, no need for advanced editorial tools (at least to start), and many systems are basically just glorified database management systems (you heard it here first: phpMyAdmin was the first headless CMS…)

Additionally, since most systems are SaaS and grid computing architectures are so easy to scale, it’s just not that hard for someone to create a new system, call it a “headless CMS” and release it onto the market.

As a buyer, separating the wheat from the chaff can be tough. How do you know if this is a company that’s going to stick around, or if it’s just two guys in a basement somewhere? If the latter, there’s always a chance they’ll be the next Apple, but the odds are long and your content hangs in the balance.

Vendor Signaling

Like any other software segment, headless vendors “signal” the type of customer they’re interested in via technical architectures and pricing/licensing models.

There are several headless vendors, for example, that have significant ramp-up time and technical hoops you need to jump through to get them productive. This is in service of larger goals like scalability, performance, security, and stability, but for a single-person front-end dev shop, this is overkill.

For smaller use cases, there are vendors that signal in the opposite direction, promising simplicity, speed, and reduced ramp-up type, presumably at the sacrifice of industrial strength attributes unnecessary for that type of project. They assume a simpler project, are designed to provide the bare minimum of features and stay out of the way as much as possible.

Documentation matters too. I just spoke to a customer who preferred one vendor over another because “their documentation was focused on editors, while [the other vendor’s documentation] was focused on developers.”

I’ve mentioned that headless is very developer-centric, but some more so than others. Many offer free accounts and API sandboxes to get you moving quickly. On the other side, one vendor requires you to load their command line tools via npm just to create a trial account, because their system has no multi-tenant UI – it’s managed mainly from the command prompt. (Once you’ve done that, you can run your own UI, also installed via npm and run in your local Node.js environment.)

In short, headless vendors have a “tone.” You can label the two ends of the scale as “industrial” and “friendly,” or targeted to developers or editors. Pretty much every customer intuitively knows what end of that scale they gravitate toward, whether they explicitly acknowledge it or not.

Conclusions

I don’t doubt that I missed some categories above. But if an omission sticks out for you, understand that it might be because there’s little difference between that aspect of headless and the same thing on the coupled side.

Community and ecosystem is a good example. Trust me, I know this is important – I wrote at length about it, six years ago – but I just don’t think this is much different for headless than for any other type of CMS.

Clearly, the range of features for a headless CMS is more narrow than for a traditional, coupled CMS – by design. This means that a headless CMS has that much less room to maneuver against their competition.

A headless CMS can’t really trot out a bunch of delivery-channel marketing features which is where most other CMS segments are competing these days. Episerver and Sitecore, for example, aren’t launching any marketing campaigns around their content modeling.

Right now it doesn’t feel like there’s a dramatic, expansive featureset where a vendor can spread their wings, redefine the segment, and put considerable distance between themselves and the competition. To some extent, headless vendors are locked in a knife fight inside a phone booth.

Years ago, I made a series of posts about WS_FTP, which was a very mature FTP client. They kept pushing it out the door with new features, year after year. Some were interesting (automatic image thumbnailing), and others were ridiculous (custom skins). But what choice did they have? The only way to keep selling is to release new versions with new features (ask Joel Splosky about this), so they kept pushing functionality into the product.

But FTP will only do so much, and FTP clients are highly fungible. So, despite all their efforts, features, and bloat, WS_FTP was still pretty much like any other FTP client.

Now, I know that the headless market still has a lot of room to grow, but eventually headless vendors will reach feature parity on lots of stuff. Is there much new ground to break in content modeling, for instance? When that happens, then what?

So, my question is this: what’s the “killer app” of headless CMS? What is the thing that a particular vendor might obtain or introduce that would set them apart from everyone else, while still allowing them to fit into the standard definition of a headless CMS? Can you imagine what that thing might be? Into what realm will a vendor “spill over” into when features become too similar?

I can’t think of anything, but this is why they pay product managers. One of them is going to get trapped against the glass ceiling of the segment, and they’re going break through it. I look forward to seeing what they come up with.