Headless Commerce: what is it exactly and what does it mean for your business

I will share my insights on the current and future state of headless commerce and provide decision-making guidelines for your specific business.

Headless commerce has become a popular term in recent years, and with that, comes both excitement and confusion. Having built several headless commerce sites since 2017 and providing daily recommendations to merchants, I would like to share my unbiased thoughts on this topic.

There are generally two questions around the topic of headless commerce:

• What is headless commerce, exactly?

As simple as it may seem, there is still a lot of confusion and misunderstanding surrounding headless commerce. I’ll explain this in a bit more detail soon.

• What does it mean for my business and what should I do about it?

To answer this question, it’s important to consider a variety of contexts. I will share my insights on the current and future state of headless commerce, as well as provide some guidelines for making informed decisions on whether to adopt a headless commerce approach.

So, what is headless commerce?

Headless commerce is an approach to architecting an eCommerce technology stack where the frontend user interface (UI), or “head,” and the backend commerce functionality, or eCommerce platform, are decoupled. Instead of being provided as one package, the frontend UI is built separately and communicates with the eCommerce platform via APIs.

Before explaining headless commerce further, let’s look at the traditional non-headless architect first.

Although there are numerous diagrams and illustrations available to visually explain the headless commerce v.s. traditional eCommerce concept, I have found that it can be most effectively demonstrated using Lego. I was fortunate enough to borrow some Lego bricks from my 4-year-old son to aid in illustrating this concept.

The image below provides an example of a traditional/Monolithic eCommerce website architecture, where both the front-end UI and back-end functionality are provided by the eCommerce platform itself.

The two components are coupled together and cannot be separated. If you wish to move to a new eCommerce platform, you will need to rebuild the front-end UI entirely. For instance, if you switch from Magento to Shopify, you will have to rebuild both the front-end and back-end of your site.

This same principle applies to traditional CMS architecture, for instance, WordPress, where the front-end UI displaying information and the back-end functionality hosting and processing data are also coupled together. (See image below)

Let’s now explore the simplest form of headless commerce architecture where the front-end UI and back-end functionality are separated without introducing any additional system. (See image below)

The front-end UI is built outside of the eCommerce platform and is represented by a different colour in the image. This results in a more complex system with two separate components: an eCommerce platform and a headless front-end UI.

You may be wondering why we would want to separate the front-end UI and back-end functionality (the eCommerce platform). Isn’t it complicating things? It’s true that this creates a more complex setup, and if all you need is a standard eCommerce website with basic functionalities, then there’s no need for a headless architecture. However, there are cases where headless makes sense.

The headless architecture can be especially valuable in two use cases

Use case 1: Content-focused website or website with an unconventional purchase journey

If the website focuses on providing content and resources to your customers or delivering unique experiences that go beyond the typical “browse product listing > see product detail > add to cart & checkout” journey, then headless commerce would be a good fit.

In this case, the architecture will look like the picture below. With a headless frontend that connects to a headless eCommerce platform and a headless CMS platform.

Your content and marketing team can provide engaging content to your customers while maintaining strong eCommerce capabilities.

If you take it further with additional customizations on top of the eCommerce and CMS platforms, you’ll get the architecture shown below, where the white block represents customizations unique to your business implemented as microservices.

This is currently the most popular setup in headless commerce architecture.

For example, one of Moustache Republic’s clients, Vodafone New Zealand, has a website that focuses primarily on content. About 95% of web pages on the site are content pages. However, the site also provides eCommerce functionalities, such as purchasing mobile phones, mobile plans, and broadband plans. Further to that, the pricing rules for mobile and broadband plans are complex and not adequately addressed by the eCommerce platform itself, so additional microservices are also necessary. In this case, the headless architecture allows for a seamless experience for customers, with just one front-end UI that connects with the headless CMS and eCommerce platforms and additional microservices. Without the headless architecture, Vodafone would need to build a content website and an eCommerce website respectively, which would add more friction to the customer experience and require additional maintenance overhead.

Use case 2: When you have multiple digital touchpoints that provide commerce functionalities

If you need to implement commerce functionalities outside of a traditional website interface or when you have multiple digital touch points with your customers, such as a mobile app, kiosk machine, embedded shopping in AR, or in-car displays, a headless architecture will be a good fit. In fact, headless commerce was born for this particular reason.

In this case, the architecture will look like the image below, where multiple front-end UIs share the same set of back-end systems.

This is the ultimate headless commerce setup and where you get the most out of the headless architecture. In the picture, each coloured lego brick at the top represents an interface, which could be a website, kiosk display, mobile app, smart speaker, IOT device, or even metaverse. This setup allows for a unified back-end system that can be used throughout all of these front-end UIs, even where there’s no UI (voice commerce). Actually, the image is not 100% accurate, all three lego bricks at the bottom (the backend systems) should’ve been connected to all three lego bricks at the top (Frontend UIs). However, I’m working with the limitation of lego bricks and I think you get the point anyway.

In this architecture, you can add, update, and remove each of the components without impacting others and that’s the essence of headless commerce or headless architecture in general. Tesla is a good example of a business that could benefit from this architecture, as you can browse content and make a purchase in all their digital touchpoints, such as the website, in-car display, and mobile app. All these UIs are connected to the same backend systems via API. I’m not sure if Tesla actually uses this architecture, but they certainly should if they haven’t already.

Now that we’ve discussed the use cases for headless commerce, it’s time to debunk a couple of common myths about this architecture.

Myth 1: Headless commerce is more flexible and customisable.

Firstly, we need to define what “more flexible and customizable” means.

At a bare minimum, there are two components in a headless commerce architecture: the front-end UI and the back-end commerce functionality. If we are talking about the flexibility to replace one component without impacting the other, then yes, it is. Taking the example of migrating from Magento to Shopify, if your Magento site was built in a headless way, you have the potential to migrate the backend eCommerce platform to Shopify while keeping the front-end UI untouched. It’s not going to be as straightforward in reality but this is possible with a headless commerce setup.

In terms of customisation, it will be more customisable if you have a CMS platform as part of your headless setup. You’ll be able to provide more content related functionalities to your customers. Keep in mind though, the additional CMS platform will also add complexity to your system, too.

However, if what you are trying to achieve is just a fancier-looking UI and UX for the eCommerce website, then your traditional eCommerce website setup is just as good as headless commerce is. You can achieve any look and feel you want with the templating engine provided by your eCommerce platform. The headless architecture is not superior in any way in that case. Keep in mind, headless commerce is just a way to architect your tech stack, and it does not imply any superiority of technology used within that architecture.

Myth 2: Headless commerce sites are faster in terms of page speed.

Well, this is not entirely true either.

Let me explain. Headless commerce is simply a way to architect your commerce tech stack, and you still need to choose the technology used within that architecture. In other words, the performance of your system depends on the tech stack you choose for each component. You can opt for standard HTML, CSS, and Javascript, or choose modern technologies like React, Vue, and more specialized frameworks like next.js Commerce and Vue Storefront which are known for their superior page speed optimization.

What really matters is the technology choices of your front–end UI and the eCommerce back-end system, with the former having a greater impact on page speed as most eCommerce back-end platforms provide fast enough APIs already. This same concept applies to progressive web apps (PWAs). In short, the performance benefit of headless commerce is a result of modern front-end technology rather than the headless architecture itself.

So why do many people still believe that headless commerce sites are faster than traditional eCommerce sites? It’s because most headless commerce sites are relatively new and built using modern front-end stacks such as next.js Commerce and Vue Storefront. These frameworks tend to outperform the templating engines native to the eCommerce platforms. These native templating engines were typically built before the modern stacks gained popularity. However, as modern eCommerce platforms continue to build their native front-end UI with modern tech stacks, the performance gap between headless and traditional eCommerce setups will gradually shrink.

Even though we’ve debunked the myths, headless commerce is still a more advanced architecture. So, why wouldn’t every business adopt it now?

Well, there are a few downsides to a headless commerce implementation at the moment.

Complexity

With headless commerce, you go from having one platform to provide all your eCommerce functionalities to having at least two, sometimes even multiple systems, including a headless CMS platform. This setup can complicate your system, and introduce more bugs, errors, and maintenance efforts. Having a separate front-end UI means that many of the apps that work natively with your standard eCommerce platform will need bespoke implementations for your front-end UI, making implementation complicated if your site uses a lot of these third-party apps. This leads to the second downside, which is the cost.

Cost

A headless commerce setup can be more costly because of its complexity and bespoke implementation and custom integration requirements. It takes more developers and experienced developers to maintain a headless commerce setup. Also, whenever your eCommerce platform has a feature upgrade, you’ll be responsible for implementing it on your custom front-end UI manually, which increases your total cost of ownership.

Lack of standardisation

Another downside is the lack of standardization in the tech stack used to build a headless commerce front-end UI. You can use vanilla React, Angular, and Vue or use a more tailor-made framework for eCommerce such as next.js commerce, Vue Storefront, Shogun frontend etc to build it. As of now, there’s no clear winner in the market to provide a standard for implementation.

I reached out to six top eCommerce agencies in Australia and New Zealand and found that they all use completely different tech stacks for their headless commerce implementations. This means that if you rely solely on an agency to build your headless commerce site, you may be stuck with them for the long haul. The chance of another agency taking over your headless commerce site is significantly lower than with a traditional eCommerce site built using the native templating engine. Despite the fact that “Shopify + Sanity + next.js” is already a fairly popular tech stack in comparison to others, it’s still not standardised, making it difficult for merchants to switch providers. In fact, we’ve had to turn down a few merchants who were seeking our support for their headless commerce site because we don’t use the same tech stack on which their site was built.

So, will the situation get better? Absolutely!

There are two trends in the market that are working to solve these problems from different angles.

Firstly, there’s been an explosion of dedicated headless frontend platforms like Vue Storefront, Shogun Frontend, and Next.js Commerce which aims to standardize front-end UI technology and provide native integrations with popular eCommerce platforms such as Shopify, BigCommerce, Magento, and commercetools. With one or two of these front-end platforms emerging as clear winners, it’ll simplify the implementation and enable merchants and agencies to adopt headless commerce more cost-effectively.

Secondly, eCommerce platforms like Shopify and Commercetools are taking the initiative by building their own headless front-end UI or acquiring existing ones in the market. Shopify, for instance, has its own headless front-end platform called Hydrogen, which is further enhanced with the recent Remix acquisition. Meanwhile, Commercetools acquired the headless front-end platform Frontastic in November 2021 and rebranded it to Commercetools Frontend. I’m hoping that eventually, all eCommerce platforms are by default built in a headless way, standardising the implementation and dramatically reducing the implementation costs. As a result, existing third-party apps built specifically for these platforms will natively integrate with these headless front-ends too. I’m personally very excited to see further development in this space and more platforms taking this approach.

It’s time to tackle the million-dollar question: “What does it mean for my business and what should I do about it?”

As I mentioned earlier, this question requires a lot of contexts. Before providing recommendations, I typically ask the following questions:

• Does your business have a use case that fits into the two use cases described earlier?

Are you heavily focused on content or do you have a unique purchasing journey? Or maybe you have multiple touch points with your customers, such as a website, app, or kiosk, that all provide commerce functionalities? Answering this question is crucial because, at the end of the day, any changes we make to our system should solve a problem or fulfil a need.

• Do you currently have a separate CMS and eCommerce site and do you see the possibility of replacing one with the other?

If you do have a separate CMS and eCommerce platform and one cannot replace the other, it generally means you have a great focus on content. In this case, it does make sense for you to optimize your architecture by going headless.

• Do you have internal technical capabilities?

Headless commerce is a more complex setup, and it helps when you have the internal capability to support the complexity. It also means it’ll reduce reliance on your agency. As I mentioned earlier, different agencies use different tech stacks, and you don’t want to be locked into just one agency. On this front, make sure you do your research and choose a popular tech stack rather than solely basing your decision on your agency’s capability or recommendation. There’s also a hidden benefit if you have an internal technical team. Headless is a newer and more advanced architecture, and the fact that the headless front-end UI is usually built with modern technologies will help you keep your tech team entertained and even attract new talents. This is one of the reasons why agencies love headless commerce — we need this new toy to make our team happy and attract new talents.

• And last, but certainly not least, do you have the budget for headless commerce?

While staying on the cutting edge of technology can have its benefits, it’s also expensive. You have to make sure you have the appetite for it and that you understand the additional investment required. The cost can be 30% or more compared to a standard eCommerce implementation, both for the initial build cost and ongoing maintenance. So, the ROI has to make sense for your business.

To me, a business should answer positively to at least two of the questions above before committing to a headless commerce setup. That’s the general guideline I use before making more tailored recommendations.

Finally, I’d like to use these guidelines to share some recommendations in a more straightforward way based on the business size.

Keep in mind that without knowing the specific details of your business, it’s impossible to give you a perfect answer. However, I’m happy to share my thoughts and provide some insights that might help you make an informed decision.

Small businesses

As a small business owner turning over less than $5 million (AUD or NZD as I’m based in New Zealand) in revenue, I generally do not recommend headless commerce architecture unless you have a specific business case that requires it. However, to future-proof your business, I do recommend moving to a SaaS-based eCommerce platform that is headless-ready. Platforms such as Shopify and BigCommerce have mature APIs that can be used in a headless manner while also providing a cost-effective non-headless templating engine.

Mid-market businesses

For mid-market businesses, the decision to adopt headless commerce is complex and depends on several factors, such as the size of your business, the vertical you are in, and the maturity of your internal team. While investing in a modern frontend tech stack and implementing headless architecture can give you a competitive advantage, it can also be costly. If you have the need or appetite to stay at the forefront of technology and are willing to invest knowing all the potential downsides, then go for it.

However, it’s also reasonable to wait a little longer. eCommerce platforms and emerging headless front-end platforms are heavily investing in the space, and the headless space is developing at a fast pace. In the near future, headless implementation will be more standardised and cost-effective. It would be an ideal time for most mid-market merchants to adopt headless commerce when these three things happen:

• the headless front-end natively supports apps commonly used on the eCommerce platform,
• the headless front-end automatically adopts updates from the eCommerce platform with minimum to zero manual effort
• there is built-in content management capability provided by either the headless front-end platform or the eCommerce platform

Final words

While my team at Moustache Republic was one of the earliest adopters of headless commerce and love it, I’ve seen many merchants making the move to headless without fully understanding the implications. Don’t jump into headless out of fear of missing out — it is important to adopt it for the right reasons and to understand all of its implications.

I hope this article provides the insights you need to make an informed decision about headless commerce. It’s time for me to return the lego bricks to my son and thank him for his contribution to the eCommerce industry 🙂