In last week's post, I reviewed the concept of headless CMS architecture, the state of headless CMS as a business, and provided some clarity to the muddy messaging that exists related to the idea itself and services headless providers offer. This week, I want to talk about some options for standing up your own headless CMS, quickly and easily.
As we reviewed previously, some headless providers are charging upwards of $40,000 per year or more to utilize their service. Yet, we all know that to use these services, you still need development capacity to build the presentation layer. So, assuming that you already have development capabilities, why not just build your own headless CMS or grab an open-source one and from there maintain it?
The skeptic will ask, "Why?" Why develop something that so many providers already have? After all, they have invested countless dollars in making those platforms reach maturity. Well, my answer to that comes down to a few factors. First, they've spent all that money taking a simple concept and making it applicable to a broad user base. Headless is not a complicated concept, as we've reviewed. The reason headless providers are blowing through tens of millions of dollars is that they have to add functionality to compete with each other continually, and then spend even more marketing against the 30 competitors they have.
Secondly, building it will enable you to control how this simple concept aligns with your particular requirements, and the result will be something that can be an asset to your company for many years to come. Building is the best way to harness the simplicity of headless while saving you an ongoing, expensive license relationship. Where this is particularly valuable is with almost any custom functionality that you may require. Headless CMSs are not capable of managing complicated, interactive elements (though, surely they will tell you they are). They can't handle interactive server/client communication that you'd be capable of doing with on-premises systems that are open source. As such, if you have any inherent complexity in your requirements, headless, hosted solutions won't work without major workarounds. You'll either have to go back to an older architecture or build a new approach to the problem.
Thirdly, my last point to be made in the build vs buy debate is the concept of usability. For marketers, the abstract nature of a headless CMS is simply too confusing to use. Marketers are used to systems that have all layers of marketing tools, content management, form management, etc. all under one umbrella. You can't integrate the tools marketers use in any useful way to these headless platforms. Your best bet is to do it yourself, building a usable UI/UX along the way for which your team will thank you later because they had an actual hand in developing it.
One final note as I introduce this blog. Some may define "headless" as only being headless if you are absolutely uninvolved in the development and management of the solution. They claim that is what removing the "head" means. I disagree. Headless is an architecture, not a license or business model. Therefore it's completely possible that you can implement this yourself and manage the head as a separate entity of your infrastructure.
Now, let's discuss how you can build or deploy these systems yourself.
Open-Source Projects Versus Custom-Build
The first part to discuss is whether or not to utilize an off-the-shelf project for this purpose or to build one yourself. Well, like everything else, the prescription requires a diagnosis. Is your site informational or marketing-driven? Well, in that case, you may just want to use an old-fashioned integrated or coupled CMS anyway. Sorry – I had to!
But, let's say you've already done some discovery work, and you know that headless architecture works for you. At this point, it becomes a debate on the functional requirements your project may have. If you have minimal features requiring server interactivity such as writing data more than reading and your project is mostly the collection of content for distribution to multiple channels, then there are many headless CMSs that you can download and utilize. This website very handily lists every headless CMS out there and filters it by license type. Check out the open-source options, and you can see there are platforms for almost every tech stack. Some are better than others, but projects such as Strapi, Cockpit, and Directus are very compelling offerings.
However, the buy vs. build debate always rages on once you realize that your proposed project is a bit more sophisticated than something purely informational. If you have some highly interactive features, custom workflows, or functionality that is somewhat more complex, such as advanced commerce, login portals, or anything requiring more server-side processing – in that case, the possibility of building a more bespoke solution is on the table.
Building a Headless CMS
I'm going to throw a question out on the table to start this section. Can't any application built utilizing access to an API to collect content, and administrated via a separate interface be broadly categorized as being headless? I'm 100% sure you can refer to this as being decoupled – pretty much everyone agrees with that. But the majority of definitions of what defines a headless CMS revolve around the concept of the API delivery of content. One provider even refers to their system as an "API-first CMS". So, therefore, isn't any full-stack developer by default a headless CMS specialist?
And, by that logic... Geez, couldn't you make a headless CMS out of Airtable? Oh... wow - you can!
Sure, the headless providers will all claim that it's their specific methodology that makes them truly "headless." The ability to define content types, allow for centralized administration of content, and delivery via an API is generally what the accepted definition is today. But in reality, almost anyone developing an API-based application is already playing in the headless world, right?. And those folks know that inherently, these are simple solutions.
So why did I start by mentioning this? Simple: to show you that headless architecture has already been powering applications for a very long time. So, therefore, it's completely viable that you can do it yourself. And in bringing things back full circle, it seems as though we've entered another era of viability for the custom CMS…?
Let me start with a ridiculously simple headless roll-out. This would be using a database management system, such as phpMyAdmin or similar, building out a simple series of data tables, and then using a library to make the information available via an API. Yes – this is super simple and not a competitor to any vendor or project out there, but it is, in theory, headless content management, right?
How, though, would you build a more comprehensive headless system? Ideally, you'd spin out a stack that has an easily scalable database to start, then utilize an administrative UI/UX (or spin out your own) from which you could craft some tool to manage content. It may be a bit more complicated, though not impossible, to allow administrators to change content types themselves in the future. Though, why bother, because they already need a developer on call anyway to handle the presentation layer of their content, and how often do content types change, anyway?
For API delivery, you could utilize any series of code libraries to accomplish this. All of the leading frameworks allow for this. I mainly have been a fan of PHP, which would enable one to use Laravel as a framework, and features a robust API library. But you could also utilize Node.js or any other number of options. It depends on your development capabilities and also your long-term plans.
A decent line up of solutions I'd consider:
Infrastructure:
- Hosted DB via AWS: either an instance of MySQL/Mongo or utilize Amazon RDS.
- A single EC2 instance for API delivery and hosting CMS.
Coding Frameworks:
Caching:
- Either utilize AWS microservices or…
- Cache on the server itself with server-side libraries.
As a disclaimer, this is based 100% on my LAMP background and preference. There are 50 ways you can do this in the open-source world with low-cost hosting.
Standing up a simple headless CMS should be something a full-stack developer could do in a single month with full-time effort if even that. In fact, I'm being super generous with that estimate. It would be secure because it lives away from the content presentation layer, hidden from the world. It would be scalable if you used the right micro-services along the way.
What are the economics of building? Let's say you hire an outsourced developer for $150 an hour, and it takes them 160 hours of full-time work to stand up the system. That's about $24,000. Add up a year of hosting and microservices – probably you are at $30,000 total cost – which would allow for a very high traffic figure. This is lower than many headless providers, and the budget impact in subsequent years will be much less. Plus, you own it, are not worried about underlying technology changes with the provider, and you are most definitely not concerned with the provider's viability as an entity—all things worth considering, which we discussed last week.
Surely It Can't Be This Easy…
You're most likely calling me out for a load of BS at this point, and that is fine. You may have some legitimate points about the features and capabilities of licensed headless systems. As an example, how can a company that raised X millions of dollars have a product I can make myself? Well, you can make peanut butter at home too, but Skippy is still being sold around the clock, right?
In defense of this approach, I want to make two points for consideration, some of which I mentioned above. First, those licensed systems are designed to handle as many use-cases as possible. This means that they have to spend development time, making sure that the systems can have these various capabilities and compete with a broad range of competitors in the CMS space. Most of their product development resources at this point are going to this type of work and not necessarily improving the architecture of the system, which frankly hasn't got much further of an evolution roadmap at this point.
Secondly, many of the features that make those systems so powerful are taking them more down a path away from what a headless CMS truly is. Remember my assumption: a relatively simple system is required which would make content available for publishing. That's what the use-case for headless CMS is. Everything else on top of that is fluff. You can't build a product category on fluff. Or maybe you can, as there are 30 of these systems out there, at least.
So yes, it is this easy to deploy a real, headless CMS in a production environment.
Wrapping Up
I feel I've said it at least 20 times – I love headless architecture! Almost every custom CMS project we do today is headless or decoupled. I still, however, wonder about the size and scale of the category providing the service. I understand that there are always going to be folks who want to find a software solution for everything, and with that said, there will be licensed headless solutions available for years to come—hopefully, just fewer of them with some level of standardization.
Nevertheless, given the relative simplicity of what headless is, and the fact that even in licensing these solutions you will require expert development support, I couldn't in good faith recommend paying massive license fees for something so easily deployable on your own. Hopefully, this post will help those overcome the fear of bespoke approaches to problems by highlighting how simple they can be, along with the added savings of budget and reduction of overall risk.