The harsh truth: you’re wasting time overcomplicating web development.
Headless CMS has been slated as a shiny, exciting object that can solve the problems that legacy CMS’s (think: Wordpress, Wix, Adobe, Drupal, etc.) bring up. Headless CMS platforms like Contentful, Strapi, and the like promise:
Better omnichannel capabilities
But often, headless under-delivers on its promise, especially when you’re working with a small team or limited resources that need to get their content out the door fast. The majority of web projects do not need a purely headless CMS.
The unfortunate reality of purely headless CMS
In reality, what most companies find when they start working with a purely headless platform is the following:
No built-in visual tools for non-technical teams
Visual tools like side-by-side editing and preview are not available in most headless CMS platforms. Integrations or custom tooling may be able to get you there, but most non-technical teams find they have a frustrating time with headless. Marketers and content authors are unable to see the changes they’re making to the website; that’s like trying to paint the Mona Lisa in the dark.
Less autonomy for teams
No matter what freedoms pure headless CMS platforms promise, everything is dependent on development teams. Simple changes need to be passed through the development team, instead of content teams being able to make edits directly, which ultimately means more work for all. A headless CMS causes more dev tickets, not fewer.
Lag-time between content publishing and when it’s live
Because of how headless works, publishing is not instantaneous. Therefore, changes to the website (such as bugs, updates to fix crashed pages, or critical design updates) take longer and can harm business overall. This can be minutes, hours, or days, depending on the size of your site. Generally speaking, the bigger or more complex the site, the longer the build time.
Lack of SEO capabilities
Many headless CMS platforms do not provide direct editing of URLs, metadata, 301 and 302 redirects, image optimization, schema tags for accessibility, and more. Those familiar with the quick editing provided by Yoast in Wordpress will be frustrated with the dependency on development to update simple SEO properties, let alone the more technical functions to improve optimization.
This puts the emphasis on web developers to understand and optimize SEO, which takes time away from their primary goals.
Pure headless is just more expensive, period.
More headcount and highly-skilled developers required
There are many reasons why headless CMS can incur more costs than meets the eye, one of which is the development firepower needed to make it successful. We feel this should be one of the biggest considerations when choosing headless.
Building headlessly typically requires more headcount dedicated to the project, which in turn drives up business costs. Additionally, it requires more skilled developers who understand more than traditional web development, like local environments, Node.js, APIs, git workflows, and more.
More software than you may think
Purely headless CMS is just one piece of the puzzle. Companies are still left responsible for the rest of the architecture and infrastructure required to make your build successful, including (but not limited to):
Web page hosting
Software hosting (if self-hosting)
Private cloud component
Content delivery network
Firewall and security
Lost revenue due to marketing gridlock
This is the biggest drawback of headless for most teams. Those who are used to working in CMS platforms that provide preview environments and direct publishing find headless to reduce their work autonomy and increase friction in the publishing process. Workarounds can be created to provide preview environments, but those also have to be maintained by the development team.
Ultimately, longer development time
Headless CMS’s promise faster development due to the nature of developing headlessly: content and development teams can work simultaneously to produce what they’re responsible for.
It sounds like a dream come true; however, headless development is complex. Without the features listed above such as preview environments and visual editing, the back-and-forth between content and development teams compounds. Many of our clients have come to us after even just a few months on other headless platforms, citing frustration around the long development times with headless.
What’s the right choice? It depends on your business needs.
Headless isn’t meant for every company. In fact, most companies are probably doing themselves a disservice by implementing a headless CMS, purely because they don’t need something so complicated for what they’re trying to achieve.
So what’s the solution?
We’re not going to say that headless is wrong for every situation - in fact, it can be extremely powerful for those looking to create highly complex, personalized experiences.
But for those looking to take advantage of omnichannel capabilities and flexibility that headless provides while still having the capability to actually edit content and move quickly to publish, we recommend finding a middle ground with a hybrid solution.
Hybrid CMS platforms such as Zesty offer the best of legacy and headless systems. Teams can leverage the modern capabilities of headless, such as the flexibility to place content on any channel without extra development. But they also get the visual tools and greater marketer control that legacy CMS boasts. Plus, the total cost of ownership decreases when you don’t need as many resources or integrations to get the job done.
How to determine the right CMS for your business
Here’s how to determine what type of CMS to choose:
Evaluate how many resources you have to work on your site/app/project. The fewer resources, the less likely you should be opting for headless.
Determine where you need your content to go. If it’s just going onto a website that doesn’t need personalization or eCommerce capabilities, you should be opting for hybrid. If you’re looking to do multi-channel content that’s highly complex, headless might be better, though hybrid can still serve your needs.
Ask yourself: what type of knowledge does your team have? If you only have a front-end developer, you might be better off leveraging a hybrid CMS. Even if you have a larger team, their skills may be used better somewhere other than your website.
When you should use headless:
Your website is tied to your product
- You need highly personalized content
You are building a highly complex omnichannel strategy
When you should not use headless:
You are building a standalone marketing site (that is also mobile-friendly)
You have limited resources to get the job done
You need visual tools to give your marketing team autonomy over their work
You need faster development and direct publishing capabilities
- You don't want to pull your existing product developers onto website projects