Evaluating the 4 Different Paths to Headless Commerce

Headless commerce is becoming mainstream, but one person’s definition of headless may not be the same as the next. And the most confusing part? They could both the right.

There’s no one single path to headless commerce. The different approaches fall into 4 main categories.

A commerce-led and content-led approach have been around the longest, so they’re often what comes to mind first. In a sense, these are “hybrid” approaches to headless. We think of them as hybrid because new touchpoints may be added with a headless set up, but the web’s presentation layer is still tightly coupled to one of the applications of record. The result is an architecture that’s part-headless, part-monolith.

A custom approach and customer-led approach have emerged more recently and are gaining steam as they completely separate both commerce and content functionality from the front-end. This helps maximize the agility and flexibility benefits of headless.

Each approach has its advantages and disadvantages. In this blog post, we’ll break down each one to help you determine what makes the most sense for your organization.


Commerce-led ApproachContent-led ApproachCustom ApproachCustomer-led Approach
Front-endCommerce systemCMS / DXPBuilt custom or with open source toolsFront-end platform
BackendHeadless CMSHeadless commerce systemHeadless CMS & commerce system

Headless CMS & commerce system

Commerce-led Approach

Front-end: Commerce System | Backend: Headless CMS

diagram depicting the front-end as a commerce system and back end as a headless CMS

A commerce-led approach leads with the commerce platform as the front-end and pulls in content functionality from a headless CMS via APIs.

This could be considered a headless approach because it leverages a headless CMS, but the commerce system is still tightly coupled, limiting the ability to move quickly.


  • Ecommerce teams can own the front-end and have the flexibility to optimize the experience for purchase flows, search, personalization, order management efficiency, etc.
  • Ecommerce teams can natively leverage merchandising tools, optimize product search, and connect with other applications to process orders efficiently.
  • Ability to update and publish content across all touchpoints from a single CMS via APIs.


  • The commerce system will require a major redeploy for any UX change, maintenance work, or upgrade, eliminating the typical agility benefits of headless.
  • Marketing/creative teams will need to consider how to best manage content workflows and templates/layouts prescribed by the commerce system.
  • Marketing/creative teams will have higher dependencies on the technical staff to make changes to the customer experience.
  • The CMS needs to synchronize/copy data to the commerce platform to keep it consistent with other channels. These syncs are long and time consuming, they require constant monitoring to prevent errors, and they’re inefficient because you’re paying double to store the data in two places in different formats.
  • When you want to replatform you’ll have to throw out you entire customer experience because it’s coupled to the commerce system.

Content-led Approach

Front-end: CMS / DXP | Backend: Headless Commerce System
Diagram depicting the front-end CMS/DXP and backend as headless commerce system

Today’s customers expect more than transactional, commerce-only experiences. To deliver these content-rich experiences necessary to differentiate, many organizations introduce a “content-led” approach with a web content management system (WCMS) or digital experience platform (DXP) as the front-end of their headless architecture.

These content systems allow you to do things like:

  • Personalize product pages
  • Add/update lifestyle descriptions
  • Add rich multimedia, ratings, and reviews
  • Optimize search results and recommended products
  • Synchronize content and deliver it across multiple devices in a consistent manner

With this approach to headless, the commerce functionality is connected to the WCMS or DXP via APIs. The commerce platform can be orchestrated using a microservices architecture that offers API endpoints as building blocks to design your own commerce infrastructure (e.g. commercetools) or using a more traditional stack vendor that supplies commerce flows via APIs (e.g API-led with Salesforce Commerce Cloud).

Using an all-in-one CMS or DXP (e.g. Adobe Experience Manager) as the front-end for headless commerce was a popular approach when headless first gained steam half a decade ago. But with this set up, the CMS/DXP has to perform two main functions:

  1. Act as the presentation layer for expressing backend functionality (e.g. commerce, personalization, inventory, pricing)
  2. Own the repository of digital content (e.g. creating, storing, managing content)

As a result, you don’t necessarily get the full benefits of a headless approach. Let’s look at the pros and cons.


  • Marketing/creative teams can deliver rich, immersive customer experiences that drive more engagement.
  • Editorial users can save time by using predefined, reusable layouts that have been tested for performance and usability.
  • Content workflows can be better managed and displayed across channels to improve organizational scalability.
  • New touchpoints can be commerce-enabled relatively easily via APIs.
  • A replatform wouldn’t impact the customer experience.


  • The entire CMS system has to be redeployed (which takes a long time) to implement major UX changes so the business isn’t optimized for agility.
  • Front-end and backend content functionality aren’t separated so if you wanted to change your CMS you would have to throw out your customer experience.
  • Organizationally, the marketing/creative team would own and manage the front-end creating internal dependencies and layers of approvals for the commerce team to make changes.
  • Teams that work with commerce workflows (e.g. product search, fulfilling orders, uploading pricing, etc.) would need to consider how to optimize the customer experience through pre-defined CMS templates or engage the CMS development team to change templates.

Custom Approach

Front-end: Custom-built or Open Source Tools | Backend: Headless CMS & commerce system
Diagram depicting a custom-built or open-source front-end with the backend as a headless CMS or commerce system

To keep up with consumer expectations and adapt to future technological changes, companies are turning to a headless approach that completely decouples both commerce and content functionality from the web’s presentation layer. This provides the most agility and flexibility when it comes to designing the ultimate front-end customer experience.

Since both the CMS and commerce system are decoupled, it requires that developers create a custom front-end presentation layer with open source tools or from scratch.


  • Front-end changes can be deployed independently of the backend systems, maximizing agility and flexibility and enabling an agile org.
  • The capabilities of both the content and commerce systems can be fully leveraged and owned by each respective internal team without multiple layers of interdependencies.
  • Marketing teams can manage content without any template or layout restrictions.
  • Ecommerce teams can optimize purchase flows and add any commerce functionality directly in the commerce system and connect it to the front-end via APIs.
  • Content and commerce data and functionality can be integrated in real-time presenting a continuous experience.
  • Backend systems can be changed without impacting the front-end – whether it’s swapping out your multi-variate testing system or replatforming your commerce platform.


  • Need to build or buy a hosting solution since the front-end experience is no longer living in the commerce or content system.
  • Managing the architectural platform end-to-end can take a lot of time and resources – the code upgrades alone can take a significant amount of time.
  • It’s challenging to ensure that your in-house platform is fully scalable to support real-time integration without impacting site’s performance.
  • There’s the opportunity cost of spending time and resources on undifferentiated activities like securing, monitoring, and scaling the front-end rather than building out unique experiences.
  • Costs can be unpredictable if traffic peaks during holidays or a popular promotion. You’ll need to account for higher cloud usage during unexpected high-traffic times.
  • There’s a lot of risk associated with scaling a site across multiple devices (the complexity increases if you’re working with multi-sites) and mitigating any potential of downtime during traffic peaks.

Customer-led Approach

Front-end: Front-end Platform | Backend: Headless CMS & Commerce System
Diagram depicting a front-end platform with the backend as headless CMS and commerce systems

As we saw above, custom building the front-end in-house introduces long-term risk and scalability challenges. The customer-led approach to headless uses a front-end platform as the presentation layer to eliminate these concerns.

You still get the freedom to create a completely unique customer experience built on the front-end platform, but the platform handles deployments, monitoring, scaling and security so that you can focus on what differentiates your experience.


  • Teams can offload the stress of hosting, securing, monitoring and scaling the front-end and focus on differentiating the customer experience.
  • The platform auto-scales and optimizes performance no matter the level of traffic or shopper’s location.
  • Front-end changes can be deployed independently of the backend systems providing agility and flexibility for teams to do continuous UX testing to determine what resonates best with customers.
  • Content and commerce can be seamlessly blended throughout the experience without any template or layout restrictions.
  • Built-in integration architecture allows you to easily integrate or change technologies as the industry continues to innovate.
  • Each team gets to work with consistent, streamlined workflows within their respective system: engineers/developers work in the front-end platform, marketing works in the CMS, ecommerce/merchandising works in the commerce system (don’t have to learn 3 different systems).
  • The marketing team can define content and layout as desired in CMS and specify how the content will be displayed across the web, mobile applications (Android, iOS, etc.).
  • The commerce team can optimize offerings via merchandising, pricing, and promotions directly in the commerce system and have it exposed on the front-end via APIs.


  • If your business aspirations do not include the need for content-rich experiences, personalization, or creating advanced multi-channel experiences, then a more traditional approach might be a better fit as your architecture should align with your business goals.
  • Need to be ready to level up the digital maturity of your people and processes as the architecture will enable you to work in much faster cycles.

Determining your organizations’ best path to a headless commerce architecture can be a difficult task. Follow our decision tree to identify the best fit for your business.

Get the Tool Now

Leave a Reply

Notify of
Resource ad

Subscribe to the Mobify Insights Blog

Stay in the know on the latest in ecommerce so you can effectively engage your customers and drive revenue.

Related Articles