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.