What’s the Deal With Headless?

The Gist

• Headless architecture and its flaws. Headless doesn’t limit brands to an often reductive all-in-one approach, but it’s not a perfect solution as of yet.

• Don’t accept a headless status quo. Doing so may result in technical debt and missed opportunities for growth.

• Digital collaboration is key. Headless works best when team members and their systems can work together seamlessly.

In recent years, headless architecture has been all the rage. As a veteran in the headless space for the last decade, I’ve enjoyed this fantastic ride. The results have been impressive; the developer tooling has vastly improved, and, despite many stumbles along the way, digital factories and their agency and system integrator partners have had tremendous success. 

Brands increasingly turn to headless products to keep pace with the rapidly-changing consumer demands in an ever-evolving digital landscape. This post discusses the challenges of going headless and recommends ways for digital teams to raise performance, reduce costs, and boost conversions.

The Headless Hype

Before headless, companies flocked to traditional, all-in-one platforms that offered user-friendly editors and robust tools. However, despite the convenience of those platforms, support and maintenance were cumbersome and much slower because the architecture is tightly integrated and difficult to customize. Moreover, with no flexibility in tool selection, users often had to settle for features they didn’t use or that didn’t meet their needs. 

Headless has emerged as a flexible, best-of-need alternative to traditional content management and e-commerce systems (CMSes) in recent years. Instead of brands having to “glue” together code, text, images and videos into one tangled bucket, headless decouples the back end where content is stored, from the audience-facing front end, boosting speed for the experiences and leveraging advanced infrastructure innovations like delivering content at the edge through content delivery networks (CDNs). By comparison, the all-in-one solutions require expensive custom caching and hefty cloud costs to keep up with ever-increasing page views and performance demands. 

No longer stuck with a one-size-fits-all approach, brands can now choose the optimal technology for their unique requirements while delivering engaging experiences in today’s fast-changing marketplace. 

The Problems With Headless CMS and Headless Commerce

As the desire grew for tools that could facilitate efficient delivery to omnichannel websites and apps, so did the adoption of headless architecture. And no wonder. Developers can now work with the front end of their choice instead of being stuck with a proprietary language or framework dictated by a single vendor. 

So, if headless solutions offer the adaptability and scalability that more rigid, traditional architectures lack, why haven’t headless platforms lived up to the hype? Despite the tailwinds fueling headless technology’s rising popularity, pitfalls remain:

• Marketer and merchandiser tooling has not kept pace with developer experience. With headless, developers gain front-end flexibility, CLIs, APIs, type safety, and many other benefits, which come at the price of marketing control. Without no-code and low-code tooling, business users lack the visual workspace to build and edit experiences with autonomy and confidence.

• Developers shoulder heavier workloads. Because business users can’t create channel-specific experiences with headless alone, developers must take on that responsibility. As a result, ticket backlogs for marketing-related changes endlessly permeate developer teams, reducing their time for innovation and problem-solving. 

• Content is disconnected from context. In headless, since data and content are disconnected from presentation across channels, experiences become disconnected, no longer contextual, anticipatory, or relevant to end-users. Experiences across sites, devices, and languages can quickly become irrelevant and unscalable, impeding business growth.

Related article: Should Marketing Leave Martech Management to IT?

Downside of Headless Status Quo

Accepting or inheriting a headless status quo results in two significant downsides:

• Missed opportunities for growth and innovation. By not addressing the shortcomings of their existing headless system, businesses risk falling behind their competitors who are actively embracing newer technologies. 

• A heavy technical debt. Over time, accumulating outdated or inefficient code, systems, and processes can create a complex web of dependencies and complications. That technical debt slows development efforts and reduces scalability, maintainability and overall system stability. See more details below.

Technical Debt: the Challenge of Glue Code

Technical debt arises from stitching components and content from multiple sources into a cohesive front-end display, often following a component-based design system. That integration code acts as the glue that binds systems together. The challenges are fourfold:

• Complexity with more systems. Each added system and data source requires additional code for connection and synchronization. As the number of systems and data sources increases, the complexity of the integration code grows. Similarly, more glue code is required to deliver content as more components are introduced.

• Component-level code to support flexibility. Enhancing components for more flexibility, such as by attaching CTAs to banners, requires adding fields to content models and code and logic within the component.

• Complications for personalization or other advanced capabilities. As apps and websites become more sophisticated with features like personalization to raise conversion rates or tailor experiences, more code is required to support the underlying logic. Correspondingly, the complexity of the codebase grows exponentially.

• A slowdown in productivity. Accumulated technical debt creates a “glue monster” that hinders updates and enhancements.

The process then becomes slow and error-prone, and the development team’s productivity reaches a plateau. According to Lumigo, almost half of development time might be dedicated solely to maintaining integration code.