I read an article recently which implied that headless, licensed CMS platforms are the death blow to custom-built CMS platforms. Well, if you know me, you'll know that riled me up just a bit because I view this claim as extremism, and extremism is something I'm biologically wired to argue against.
Sure, headless CMS platforms can solve many problems. I love headless architecture and believe it makes a ton of sense. We've covered the topic in this blog many times, and we work almost daily with a variety of headless providers on client projects. We even offer headless CMS development as one of our main CMS development solutions. But I always remember that when someone is proclaiming the death of a platform or system, well, they are trying to sell you some sort of productized solution. So, let's try to keep perspective. Technological implementations always consist of a series of tools, and those tools are chosen by how well they solve presented use-cases. Very rarely does one-size-fit-all. So, the talk of something being "dead" – well – I've heard that line every other week for twenty years. Take it with a grain of salt.
The particular medium for the article I read (link purposely withheld to protect the accused) was on a headless vendor's blog, where they are producing marketing content to capture inbound leads. There are other articles, too, where they discuss the benefits of headless vs. this vendor, that platform, etc. In doing this, they are basically proclaiming that their headless solution is the platform that can solve all of our ills. This is a very bold claim, especially considering that headless CMS platforms in and of themselves solve nothing without other necessary components. It would be like an engine manufacturer claiming their engine solves all transportation issues, only leaving out the fact that you have to provide your own chassis, cabin, steering wheel... you get the point! But, more on all of this in a bit.
The best way to clarify the headless ecosystem is an analysis of the undeniable truth about headless CMSs. As I said above and I'll say again – the headless architecture makes a ton of sense for some use-cases. And as a component, it can fit nicely into a technology solution for any series of scenarios. But that is what it is - a component. Headless CMSs can't solve anything standing on their own. So, what I don't understand is why anyone would claim it is a one-stop solution to almost any content management problem. That simply doesn't add up from a technology perspective, and from a business perspective, it makes even less sense.
Before reading on – I want you to be 100%, abundantly clear on my message lest we are confused – and at the risk of losing some friends in the space. While I love the headless architecture, I'm sure it isn't the best solution to most problems, and beyond that, I'm unsure why anyone would pay ongoing fees to license it at current price points. I'll reiterate, a headless CMS at best is a component of a technology solution, and while it is a critical component, it can't do much on its own. The headless vendors, however, are purposely muddying the waters to broaden their potential user base, which is simply making everything worse.
Let's dig into all of this, and understand what these platforms and vendors are offering.
If the Architecture is Simple – Why Pay for it Forever?
First, I want to look at the headless landscape and the vendors that service it. I have been skeptical of the headless business model for a while now. It's one of those things that, if you know enough about something, it just doesn't seem right. As a developer by nature, I know that the essence of these tools is that they are relatively rudimentary. For years, I've proclaimed to clients that CMSs are simple: they add, edit, delete, and otherwise organize content. There is no doubt – headless systems make that part easy. You can stand up the system in minutes, start defining content types and have them published via API to a variety of channels quickly. There is no disputing that – it's cool stuff for people who appreciate this kind of thing and my technical background shows that there is a definite value.
What I am disputing, however, is why you would want to license this forever. The enterprise-level headless providers are charging in some cases thousands of dollars per month for this service. In one case, a provider is licensing its solution for over $40,000 per year. I believe there is an economic model that can build this same technology for less, and host it in an extremely economical, scalable, and reliable way at a fraction of the cost. From a business perspective, which is the perspective from which so many decisions are made, choosing a headless CMS at that price point is very difficult. It's also hard to convince marketers to spend that much for a limited-functionality CMS product when the funds could be used for more essential tools such as marketing automation, business intelligence tools, and so on.
Let's dig into each part of their value proposition and analyze how worthy these features are. First, let's look at scalability. The fact is, you could scale a headless CMS whether you take it off the shelf via open-source license or build it with relative ease. It all comes down to smart usage of tools such as content delivery networks. A headless CMS is so simple that you could run it literally on a single server instance that costs you less than $25 per month. The scalability part can be facilitated via the usage of infrastructure such as AWS to distribute your API, and some smart caching can ensure that everything runs smoothly. This isn't entirely complex – almost any full-stack developer could spin out a system like this right away. And by right away, I mean a day or two.
Security is another selling point for headless providers. Well, the fact is, securing a headless system is not an arduous task. The CMS never needs to be accessible to the world, and the data only via an API, which again, is something that could be spun off with any number of software libraries, most of which carry with them strict authentication protocols. Wherein integrated CMS platforms often have massive security issues (I'm looking at you, WordPress), decoupled or headless CMS platforms are relatively safe because their location can be concealed from the world. It would be nearly impossible for a headless CMS to be found and taken advantage of by an automated bot or worm, although I could actually make a case that it's harder to conceal licensed headless CMSs because an attacker could potentially identify the provider via API calls or similar. Either way, the security claim is not unique to any headless provider but instead speaks to the architecture and methodology.
Multi-channel distribution is another argument that vendors make. But, much like the above points, this benefit is a benefit of the architecture, not a product. APIs, in general, are usually intended to be channel-agnostic. In terms of making content work in multi-channel environments, these systems don't do anything special in that regard. They store clean content, which we've written about in the past and highly recommend as a matter of course. Move along people, nothing to see here.
So with all of this said, and with the understanding that headless is overall a relatively simple application, why would someone want to license it, paying vast sums over time? In my next post, I'll discuss how you can build a headless CMS yourself, for a budget under one year of license fees, with security and scalability. But for now, I'd posit that the only reason someone would or should license this technology is if they desire little to no control over the infrastructure behind the platform or want vendor-provided support. But, given that anyone using headless needs technical assistance to utilize and deploy, it mystifies even more as to why they would pay such sums licensing when the same resources which would integrate the solution could quickly build or manage either a custom-build or open-source system themselves.
For all of these reasons, I'm happy I don't make a living selling headless CMS! And if you ask the folks who do sell these systems, they'll tell you the same things, after a drink or two.
Headless is a Single Component of an Ecosystem
When you look over the websites of the most popular players in the space, they make it seem as though their platforms can stand on their own as solutions that compete with many different CMS platforms. You must understand that this simply is not true. If anything, the level of relevant expertise you need to utilize a headless CMS and create a proper content delivery channel is more complicated than most other CMSs. This is why it's rare that we see headless being requested by customers. There is no way we can convince a marketer or CMO that a headless CMS is going to make their site administration more convenient – because it never will. You would have to conveniently leave out a slew of information to make that sale. Sure, I've seen numerous projects where we could potentially recommend a headless or decoupled architecture, but it has been rare that it doesn't involve more complex functionality, which automatically eliminates the licensed models anyway.
Why?
It comes down to content delivery. A CMS is an internal-use system. To make use of the "C," you need a presentation layer or some other application. This means websites, mobile apps, OTT devices… And to build these, you'll need a developer, because the way you translate API-driven content into a presentation is via development. There aren't many off-the-shelf resources that make this easy for a layperson. While I believe systems like WordPress have made a million people think they are a developer because of how easy it is to spin out a website, I do have to applaud that it's actually something the masses can figure out. Headless is not such a scenario.
In reality, a marketer isn't interested in procuring a CMS that has almost no web-based editing tools (more on this in a bit), then paying a developer to code an experience which in the future will be challenging to administrate. It's a trendy tech, but it isn't practical in most situations.
But despite this, marketers need to be sold to. I'm shocked to see some headless providers flaunting connectivity to marketing automation tools in their sales materials. What is it they are connecting to, and for what purpose? It makes zero sense. It's just hype to appeal to marketers; it's based on very little practical, usable functionality.
The truth is, to make headless work, you will require skilled developers on staff or on retainer to continue to improve your site or application. Wherein we see customers take traditional web CMS platforms and run with it for sometimes years without needing technical guidance, customers who come to us with headless systems are consistently spending more money on technical changes and upkeep. We saw this just recently as we onboarded a company that was managed on a headless platform and utilized a static site generator. They have spent a couple of hundred hours against things that in other CMS platforms would've taken a day or two. That's real money, spent on a full-stack developer, which is a different price point from a WordPress developer.
Sure, if you have talented developers on staff who can be taken off of product development or whatever they are doing to manage a marketing website – then headless may make sense. To which point I'll throw this out there – why license? You can spin out your own stack with your in-house resources and save costs. In fact, that sounds like a good topic for an upcoming post!
The Headless Identity Crisis
It's worth noting that Headless CMS is a system that is not a comparable solution to an off-the-shelf on-premise CMS, especially one focused on web delivery. Yet, that is where the vast majority of opportunity exists in the CMS world, and as such, the vendors can't afford to ignore these use-cases. By addressing these scenarios, headless CMS vendors have created an identity crisis for themselves, as they want to be content-first but also want to compete with WCMS platforms. Sadly, you can't have it both ways and stay authentic to your mission. Since the concept of a headless, content-first CMS is too simple to stay in business and evolve, they are working to broaden their market by adding WCMS features. However, in doing so, they are also fighting the idea of what headless really means. You can't be genuinely channel-agnostic and content-first if you are giving people tools aimed at modular web content management. It's inconsistent at best and disingenuous at worst.
Headless systems can and never will be comparable to integrated CMS platforms such as WordPress, Drupal, Kentico, or SiteCore. Honestly, they probably shouldn't be. They are different products that do different things.
Viability of Headless CMS Companies & Projects
I know this is going to be a controversial part of this post, but it has to be said. The headless CMS space is overpopulated - there are too many players. As I write this amid the Coronavirus / COVID-19 crisis, I think to myself that our industry has simply too much software available, trying to do too many things. We're overpopulated with SaaS solutions! Take a deep look at the headless arena: CMSWire wrote an article identifying 34 players. How can 34 companies and projects be offering something so simple? It simply isn't sustainable. Given that the space is overpopulated, what CTO is going to recommend to their management that they invest in a platform powered by a venture-backed company in an overpopulated space? The chances are high that you'll have to do another vendor procurement in a short period of time.
The naysayers will say, well, you can flip a headless CMS easily enough. I guess, maybe? But why even put yourself in that position when there are so many stable options out there?
And to further the argument, you have to consider the role a CMS plays. While it may be just a component, it is the CENTRAL component in most cases to what you are building. Who is going to build out infrastructure that consists of a lynchpin component being provided by an early-stage start-up? For a risk-averse CIO, it's a non-starter! We're talking about technical environments where open-source projects that are 20 years old are still not accepted as being viable...
Setting aside viability, I'd also be concerned with the product roadmap. If you are building a multi-channel system of content distribution, I'd definitely want to own the API powering it. I'm unsure any company will want to be notified out of the blue that a significant API adjustment will result in them needing to change all of their distribution channels. The amount of dependence on a third party is simply too considerable a risk to mitigate.
What's the smarter course? An open-source project or building your own. Because headless is so simple and the core use-case is not complicated, there is an argument to be had, which says that an open-source version can be installed and survive for an extended period. The platform is hidden, so you are not worried about security updates. It's open-source, so you could amend it. And if it were to change substantially, you could opt-out of those improvements and keep it exactly as it is. What's not to like about that model? Or, to counter the article that made me write this post in the first place - why not just build it? You can spin out a simple DB, an off-the-shelf UI, and some API libraries and do the exact same thing, patterned against your workflows (of which everyone has an opinion), relatively quickly.
Legacy CMS Providers and FOMO
As we reviewed all the players in the space, we would be remiss not to mention the more significant vendors who are offering headless as a feature. Many licensed systems and even the open-source projects are doing this. I have mixed feelings about this, but I understand that when properly contemplated, it can make sense.
First off, decoupled or API-driven content delivery on top of one of these platforms makes sense if you are already committed to a CMS but interested in adding another channel of distribution. In this sense, if you are running Sitecore for your enterprise or WordPress for your business, and you are now interested in sharing the content managed in those platforms with, say, a mobile application – then, by all means, this makes sense. Go for it.
However, if you are looking to build a sophisticated delivery layer and want to use these platforms as primarily a headless system – don't. They aren't designed for that. The content model was built around web delivery. It makes zero sense to utilize software built for an entirely different purpose.
Why does almost every CMS project or vendor offer some level of API capabilities? Well, first, because it is a no-brainer to give access to content via these pipelines. What is problematic is when these vendors are attempting to compete with proper headless systems. It's is also disingenuous, at best, because integrated CMS platforms are architected for another purpose. This marketing tactic is simply FOMO, or fear of missing out.
IN CONCLUSION...
In wrapping up this post, first off, I'm glad you are still with me - I'm over 3,000 words! And secondly, I want to reiterate – technology solutions are just that – solutions to problems. But there is no such thing as one solution to all problems. Headless providers are struggling to broaden their niche in a highly competitive space. The problem is, the more they broaden, the further they travel from their core reason for being. And as they broaden, they are adding noise to an already complex ecosystem where frankly, some clarity could be used.