Differentiating Headless CMS Products

The headless CMS software space is crowded with competitors, which can make it difficult for prospective customers to evaluate available offerings. This blog post presents some criteria that can help to differentiate headless CMS products. If you have additional significant factors by which to evaluate headless CMS products, please comment on this blog post.

When evaluating vendors, consider prioritizing the following factors. Then, eliminate vendors that are not aligned with key priorities. These are ranked subjectively by my general perceived order of priority, where true prioritization would vary by organization.

• Cost: The fastest way to eliminate a vendor is often by cost. In many cases, you get what you pay for, and you may want to get more than some of the inexpensive options offer. Conversely, your budget may not support various offerings. Still, it is important to evaluate vendors outside of your price range to know what features are available and what might be coming.
• Company: For both parties to benefit most from the relationship, the CMS vendor should be a good fit for its customers. While technology is important, people are what make a company, and what make it successful. If you cannot get accurate information that you need from a vendor easily, you may want to consider alternatives. Try to evaluate the vendor’s capabilities at managing relationships at all levels, including both the sales process and technical support for users and implementors. Consider whether the CMS vendor is well-led, well-funded, experiencing steady business, and prepared to manage growth. Ask the CMS vendor about recent customer attrition.
• Differentiating Factors: I always ask vendors to describe their differentiating factors relative to their competition and their competitions relative to theirs. If they don’t answer, I ask the same question about specific competitors. Always do some research before contacting any vendor.
• Data Modeling Capabilities: Data modeling refers to the definitions of the types of records to manage as well as potential relationships between records. Good data modeling can simplify implementation, improve ease of use, increase developer productivity, boost performance, simplify maintenance, extend longevity, and otherwise benefit solutions. CMS data modeling characteristics to evaluate include the range of field types provided by the system, the ability to group fields, the ability for fields and groups of fields to repeat, the ability for multiple content types to share common data structure definitions, flexible nested structures within field values, how to implement custom field types, and any other features for representing data in the system. For me, data modeling capabilities are more important than SaaS, which is extremely important.
• SaaS: Some headless CMS products, especially open-source solutions, allow installation by customers. I prefer SaaS hosting models, which I feel assign appropriate responsibility to the vendor and deliver the greatest value from the cloud, allowing implementation without vendor-specific installation, infrastructure, and administration knowledge. Some organizations may prioritize SaaS differently or prefer to avoid it.
• User Interface: CMS usability is critical solution acceptance and long-term satisfaction. The user interface should be intuitive enough to meet most CMS user expectations with minimal or no training. Depending on requirements, the user interface must be extensible in various ways, such as custom field types, custom tools at the entry level, and the ability to embed user interfaces elsewhere in the CMS application.
• Search: All CMS solutions should allow structured queries, but typically do not support stemming, synonyms, keyword highlighting, and other features used to search. Evaluate any search features available for use in content delivery, whether the vendor offers a search solution, or what the vendor recommends for search.
• Rules: Some CMS provide browser-based user interfaces to define rules that control various features of the CMS, such as when and how to invoke web hooks. Rules can provide a user interface that allows relatively non-technical CMS users to define logic to apply various circumstances and when given conditions apply. If the CMS stores rule definitions in the repository, then you can publish them, allowing application of rules for content delivery visitors to the published website including support for personalization. Changes to corresponding logic without a rules engine can require deployment or a custom solution with similar functionality.
• Performance: Confirm sufficient CMS performance for users at expected distance from the infrastructure. Evaluate content delivery service performance from locations that may consume content at runtime. To meet performance requirements in certain geographies, it may be necessary to augment vendor content delivery services with your own.
• Headless: Some CMS that provide content delivery engines also expose services use to decouple solutions. Using JSON over HTTPS services to separate the content delivery engine from the content management system may loosen but does not remove the coupling if solution code relies on content delivery APIs that read directly from the CMS, and especially if code access content management APIs to write data back to the CMS. To approach the decoupling objectives of headless, content delivery solutions should minimize dependence on CMS vendor APIs and data structures, especially for anything other than data access. Typical coding should have little to no awareness of the CMS, only the JSON data structures defined by the content types implemented for the solution. The content delivery solution should never use content management (write) APIs and should minimize the use of content delivery APIs and vendor-specific data structures.
• Hierarchical: Some CMS organize records into one or more hierarchies, like a subdirectory structure. Others function more like document databases, as if all the records are in a single folder. This difference affects how CMS users navigate content and availability of the hierarchical capabilities for content delivery.
• Features: Depending on project requirements, evaluate CMS features such as workflow to require approval or other processes before publication, how publication works, locking or other features to prevent concurrent changes by multiple users, support for internationalization, features for managing releases.
• Platform: While a headless CMS should look like a black box to developers, there are places where the light leaks out – the decoupling is not complete. One such place is custom user interfaces, which typically load CMS JavaScript and CSS. Resources such as code samples from the vendor are likely to be most available for the technologies used by the vendor, including build tools, coding languages, JavaScript libraries, and otherwise. Technology may be even more important when using open source or when not using SaaS.
• Update 21.September.2021: Rate Limiting. To avoid overwhelming network traffic, SaaS systems restrict the number of interactions per unit time per client. For example, any SaaS CMS customer may be limited to a certain number of content delivery API calls per second. Rate limiting can impact the performance of very busy content delivery systems, increase startup time for applications that cache the entire CMS repository, reduce the throughput of data import processes, and otherwise negatively impact performance of the solution. For a cost, some SaaS CMS vendors allow tiering of rate limitations, and some can host their software in the customer’s private cloud.
• Open-Source: While I believe in open-source software, it’s at the end of this list because I have not evaluated any vendors offering open-source headless CMS on SaaS, which is one of my top priorities. Organizations that have a commitment to open source, want to minimize costs, would like to customize the CMS or contribute to its source code, and especially those that want to administer their own installations may place open-source at a higher priority.