Headless commerce: everything you need to know

By Pete Ward

Headless brings speed and flexibility to your technical architecture – and promises better outcomes for you and your customers. But what exactly is headless commerce? Is it right for your organisation? And how do you get started? Let’s take a look.

Why we’re headed towards headless

Monolithic digital platforms had their time in the spotlight. A single platform that met all your needs. One code repository. And everyone knew what was happening across the whole system. It was glorious.

It was never going to last.

Fast forward 15  years to today. Your customers are hungry for innovation, convenience, and speed. But single commerce platforms struggle to support ever changing consumer expectations. And they can’t meet customers everywhere they want to be met.

Technology must scale. Processes must flex around development and speed of deployment. People need to work in agile environments to reduce risk and accelerate time to value.

That’s why organisations are changing their approaches to technical architecture, and are starting the journey towards microservices, APIs, cloud, and headless. Or ‘MACH’, as some call it.

MACH is a technical architecture concept. It preaches that using APIs for modular systems makes innovation easier and faster. You can pick and choose the tech you want, then only scale what you need to keep up with your customers.

For many, the journey towards a smarter, more flexible architecture starts with the ‘H’ – headless. 

What the heck is headless commerce?

Before we delve further, let’s address the confusion that hovers around headless. 

Some vendors might be guilty of pushing the idea that ‘going headless’ means you have to re-platform. That’s simply not true. Yes, it’s an option. But even more traditional platforms (like Salesforce Commerce Cloud) are capable of working in a headless state to an extent. 

Simply put, headless commerce describes the separation of your front-end (what your customers see) from your back-end (your business logic). 

Doing so makes your online shop faster and more flexible, while building unique customer experiences. 

It’s the ‘A’ in MACH that makes this possible. 

Extensive APIs let applications with different frameworks talk to each other – almost like a universal translator. This helps businesses achieve fast, flexible, and unique experiences – across any touchpoint, and through any programming language. 

Diagram showing a headless structure versus a traditional structure. The traditional structure has a single rendering output. The headless structure has unlimited outputs.
A traditional technical architecture versus a headless structure

Now, that’s exciting. Because as omnichannel commerce gains momentum, each device has its own front-end with its own code. For example, your website front-end might use HTML, your mobile app may use Swift, and your wearable device, Java. 

Through APIs and API gateways in a headless architecture, all those front-ends can communicate with your back-end, regardless of what code it uses – without stepping on each other’s toes.

You could think of your commerce platform as the Hydra from Greek mythology. Ripping one head off gives it the ability to grow more in its place. Each one is capable of working and thinking independently, making it more powerful, more versatile, and more adaptive. 

And like the Hydra, you can keep adding new heads as you see fit. 

Why move towards a headless software architecture?

Customer expectations move at a break-neck pace. Getting left behind simply isn’t an option. The customer is the channel these days, and they’re shopping and surfing everywhere. From mobile to desktop to wearable devices.

Customer-facing front-ends must keep pace with new trends in frontend frameworks, new interaction types, and nuances across regions and brands. 

But backend systems must evolve at their own pace, meeting the needs of your organisation as you centralise your systems and data to become more efficient.

We separate the front-end from the back-end to allow evolution to happen at different paces. It makes scaling your ecommerce offering so much easier. Whether you're growing and expanding fast. Or just need a little boost for that new product launch.

Having the two sides of ecommerce work as discrete systems brings about control and freedom for your content creators and experience makers. They gain the flexibility to execute the online store vision without over-reliance on development teams. 

Let’s paint a picture. Perhaps you chose your legacy system for the brilliant content management tool and were willing to put up with the not-so-good search feature. 

But then the customer verdict rolled in, and you needed a brilliant search function. So you built a custom capability for your search, and all was fine for a while. But then the DAM (Digital Asset Management) wasn’t pulling its weight, so you span up a quick fix for that too. 

Before you know it, you’re scrambling to come up with hotfixes for a host of platform features, barely keeping your head above water.

This is where legacy platforms fall short (and fall over). Custom capabilities built on top of each other make diagnosing issues in the platform painfully difficult. Updating or changing them is a goliath task. 

Headless commerce lets retail businesses be nimble and innovate in an agile manner. Because you can make changes to your front-end fast – without jeopardising essential ecommerce functions like security and checkout.

As headless commerce evolves, more and more external service providers can be used. Cart providers, search providers, checkout providers, and more. By using such services – and using API gateways to have them talk to each other – deployment speed rockets, and the cost of new features plummets.

Talking about his recent appointment as a MACH Alliance Ambassador, Dylan Valade, head of global ecommerce at PUMA, explains why they adopted the MACH approach:

With a monolith structure you struggle to keep pace with the change of new frontend experiences that become available. The MACH approach allows for easy, incremental change. Without huge investment. Or big decision making. Or a major change in the way people do their work.

Headless commerce benefits

Enabling omnichannel

Customers expect you to meet them on the device or platform they prefer. This means multiple channels. Social commerce, mobile, wearables, chat. You name it. If you haven’t got it set up, you need to, fast. But you also need to be able to do it reliably at scale. And you need to preempt and act upon the next big change (and there’s always a next big change). 

Headless is ideal for getting your digital experience to wherever it’s needed. Throw out the single template and create unique experiences for each of your sales channels. And thanks to APIs, your performance won’t suffer.

Flexible and fast updates

Growth will come from optimised experiences. This means pivoting your brand experience and customer service to meet every need of the customer. And if something doesn’t work, you can switch it out in favour of what does, easily. Content, payment options, whatever. 

Choosing what works across different channels to suit your customer. That’s the true benefit of headless, because tech moves fast and you have to keep up.

The end of replatforming

Replatforming projects can take up to 12-18 months to complete, depending on the scale and complexity, and can often disrupt core business operations during the process. 

Moving to a more flexible architecture like headless can eliminate the need to replatform. It gives you control over your tech roadmap, allowing you to pick best of breed technology to fulfill a specific role, and not be reliant on the platform vendor's roadmap.

Is headless commerce right for you?

So should your organisation start down this road?

Headless is fantastic, but it’s not for everyone. Single platform monoliths are operationally very easy, which makes them attractive. Especially for your staff. One set of code, one deployment into whatever your hosted environment, one place to do everything. Love that.

Because having more than one place to carry out all of your tasks comes with its risks. Breaking out into different services brings elevated operational complexity. When systems don’t speak to each other easily, the frustration mounts.

So, if you’re able to keep them whole – and you don’t need to separate them out to improve performance – legacy systems are a viable and good option. 

For most businesses, however, there’s an argument to go headless. Here are several use cases that may steer you down the headless route:

  • You’re unhappy with your visual presentation layer and front-end experience, and you can prove the alternative will pay for itself
  • You want to customise without agonising over custom plugin changes
  • You have existing legacy systems but don’t want to replace all of them
  • Your monolithic systems have grown and they’re slowed by too many responsibilities
  • You want to plan your architecture from the ground up and build your way
  • You’re trying to establish a presence across multiple channels and devices

If any of this rings true, then taking the head off is a brilliant starting point. You’ll see immediate benefits in customer and brand experience. Because instead of everything being coupled in traditional ‘templates’, your front-end can be built on APIs instead.

Or you can flip the logic, for a back-end use case. You may have an OMS or CRM in your existing monolithic platform that’s bogged down by a lot of responsibilities, slowing performance dramatically. 

By breaking some of those systems out, you can then build in more dedicated services that free up some of that system dependency. 

But breaking your systems up into different services can create a lot of operational complexity. And more complex systems might require dedicated DevOps teams to help all of these pieces talk to one another effectively. 

A way to offset some of this complexity is by taking advantage of software as a service (SaaS). Decoupling the front- from the back-end gives you the advantage of being able to move some items to SaaS, break down responsibilities, and re-use common tools out there. 

Where to start with headless commerce 

Make no bones about it – headless is more complex than running a single platform. Depending on how you approach designing your display layer, you may rely heavily on developers whenever you need to make changes. 

That means you'll have to consider whether to up your internal capability, or outsource. Often you’ll find yourself needing dedicated DevOps teams to help maintain all these pieces that talk to one another in often quite interesting ways. 

You can offset some of this by taking advantage of SaaS. So breaking down into microservices doesn’t always mean purpose-built code – more breaking down responsibilities and re-using common tools already out there. 

But watch your footing. There are pitfalls everywhere. The more modules you choose to build your ecosystem, the more management they will require. Getting an agency to flex up your development capabilities can really help with this. 

For those who already partner with an agency, you may find the nature of your relationship change. As you internally scale up your development capabilities, your relationship might focus more on architecture and advice over pure development. 

How do you think beyond the limits of your platform? Do you have a clear enough view of what needs designing now to cater for future success? 

Your ‘resources’ aren’t just how many developers you can field to get a job done, but also the subject matter experts you surround yourself with. 

Sure, headless is more complex. But it is definitely worthwhile. The freedom you gain far outweighs the learning curve you’re about to traverse. Once you have all your ducks in a row, the path to building your headless stack looks a little straighter. And far more inviting.

Headless commerce approaches

Now we’re down to the nitty-gritty — how you’re going to get your headless stack.

There’s a couple of things to consider before you take the plunge – with two main paths you could go down: retrofitted headless and headless microservices. 

Retrofitted headless

Retrofitted headless solutions are monoliths that have had a little something special added to them (an API layer) to make them capable of more

The API layer exposes core features to offer you a customisable front-end. With the core exposed, you can transform your legacy platform’s existing front-end experience to show off what makes your brand different.

At the same time, the dependable monolithic back-end provides the comfort of an out-of-the-box approach. Perfect if you’re launching ecommerce for the first time.

Headless microservices

Further down the evolutionary chain, headless microservices have moved beyond the bi-directional relationships of headless monoliths. Every service in this architecture model operates independently, so never steps on another’s toes.

Flexibility, scalability, and speed are part and parcel of headless microservices. You can swap them in and out as needed. Scaling them up and down based on their usage. This makes creating unique experiences a breeze. Giving your teams the freedom to experiment and innovate more easily.

Headless microservices live and breathe the test, learn, and go again cycle of agile working.

Managing your microservices

In a modern world, legacy isn’t generally an issue when you’re starting up a new initiative. There’s little reason to choose anything other than Software as a Service (SaaS) solutions or a microservices decoupled route. SaaS solutions are attractive because the service provider takes care of updating, managing, and fixing them. 

But when you decouple things, you need an extra layer of DevOps to maintain everything at an operational level. Your ability to support that will depend on the capability you have in-house. 

If you’re a larger company, you’ll likely have a robust IT department or internal developers, so you can handle most of this yourself. Or you may have a lot of people plumbing your systems or managing cloud services like AWS for you. In such a case, it’s really a no brainer to use those services.

If you don’t have this internal capability, you have two choices ahead of you: hire an agency to maintain and support your initiatives, or grow these capabilities in-house. Your decision of which is best for you will come down to the strategy of your business and what your end goal is. 

It’s a toss-up between independence with a slower learning curve, and safety but reliance on a third party. Fortunately, many agencies are exceptional at working alongside your in-house teams to provide training alongside support. The best of both worlds.

Don’t lose your head: speak with an expert

Headless is ‘how’ you get there, not the ‘why’ you are doing it, so never lose sight of the end goal. 

Brands that choose to go headless are commonly after agility, freedom of expression, and the ability to meet customers on new channels with new touchpoints. 

Ripping it all down and starting afresh is folly. Sure, you might have specific systems you detest and need gone. But you’ll also likely have systems that work and you want to keep.

Our advice? Make a plan to decouple and improve the parts of your stack that will give you the most significant ROI. Then prioritise building those first. Then rinse, repeat.

Want to learn more about what headless could do for you? Our technical consultants are here to help you get the most from your architecture. Drop us a line to explore your current and future needs.

Image credit: #WOCinTech Chat