Headless Commerce - The Good, the Bad, and the Ugly: A Practical Guide to Modern Commerce and the Future for Business People

There's been so much talk about headless commerce in 2021 it's enough to make even the most die-hard follower of online commerce dizzy. So, here's a quick field guide on not only what the term means but also a better understanding of the practical benefits and pitfalls so you can decide if making the move is valuable to your brand growth.

I've been in the tech game going on 20 years now, from starting my career in 2000 with Accenture implementing large-scale enterprise platforms, then to the successes (and some failures) in start-up land, then a brief stop in venture capital before jumping back to the other side of the table to launch Shopistry. I've seen and done enough to know that technology patterns repeat and replicate across industries and for eCommerce, we're just evolving past all-in-one solutions to a more integrated solution to power growth and scale.

This isn't new, every company at scale evolves to an integrated solution using the best providers for each need. eCommerce is simply just a little later to that party but now we're here. For some reason, solution integration was just given the odd name 'headless commerce' and confused almost everyone.

So, what exactly is 'headless' and why? What about 'composable'?

Headless commerce refers to an integrated approach vs. one platform that dictates everything, and means your customer experiences - web store, mobile apps, B2B, anything - can be launched, customized, and optimized per channel and integrated with the back office systems you need. Everything is connected with APIs and the data flows wherever it's needed. It's the natural evolution of technology underpinning scale, providing the flexibility and freedom to adapt as consumer habits and technologies change:

  • Faster shopping experiences not restricted by theme designs/functionality
  • Expand support for currencies, geography and more without having to create new stores
  • Better performance and data management, improving sales and informing decisions
  • Control of checkout and conversion drivers
  • Channel specific experiences (mobile vs. web vs. in-store)
  • Support for emerging commerce behavior (BPOIS, B2B, etc.)
  • Back office systems focused on what they're best for (eComm Admin, OMS, ERP, Payments, etc.)

Headless commerce approach is not for everyone. If you have simple purchase flows and customer experiences then sticking with all-in-one platforms like Shopify, Woo Commerce, etc. makes a lot of sense. Click here, buy that, done. But anything more complex will eventually lead to an integrated solution or costly workarounds. So if you're selling protein bars online and making millions, keep going and ignore the headless hype. Once you want your customers to maybe sign up and build their own healthy subscription box, create a community around your brand, expand t o new countries, provide more shopping channels, and more then getting on the integration train early makes a lot of sense and is really imperative for growth.

A quick note on the latest buzzy term: 'composable' commerce

Just when you started wrapping your read around headless we got a new buzzword! I think it's less confusing because it sounds like what it is; Composable Commerce basically means integrating different solutions to 'compose' your optimal architecture. What's the difference between headless and composable? Really nothing...where 'headless' is a tech term, 'composable' is the business term describing what headless enables.

Confusing? Yes, so ignore the buzzwords and just focus on the fact that both mean integrated software = flexibility for scale.

Ok so sounds good, right? Well, it's not that easy (and why Shopistry exists).

Understanding the landscape

First let's get a lay of the land. It seems like every week you'll read about a new headless commerce platform. The truth is, every software company in commerce software calls itself headless, composable, or API-first. I saw a company use all three in one paragraph on their site! That's some buzzword magic.

Here's how to break them down and there are a number of awesome companies across these segments:

Backend + APIs Companies:  

  • Companies that provide a eComm Admin, PIM, or other backend applications and also an API you can use to build your frontend experiences
  • You need to build, host and manage your own stores, performance, and front end infrastructure
  • You may need to now or later, re-platform to their backend solution

Middleware + API Companies:  

  • Companies that do not provide eComm backend or frontend capabilities but act as a middleware with integrations to 3rd party providers
  • Also provide APIs/SDKs to build your own store
  • You need to build, host and manage your own stores, performance, and front end infrastructure
  • You need to be signed up for other providers for eComm Admin, PIM. CMS, etc. that are supported

Frontend + API Companies:

  • Companies that provide frontend web application frameworks with APIs or methods to connect to backend providers. These are mostly open source frameworks that give you a starting point for building your headless experiences.
  • You need to build, host and manage your own stores, integrations, and front end infrastructure
  • You'll need to build and manage integrations
  • You need to be signed up for other providers for eComm Admin, PIM. CMS, etc. that are supported

At Shopistry we took a different path. In a nutshell, we asked 4 questions:

1. Why does every brand need to start becoming a dev shop just to scale and grow?

2. There are common growth features and needs (plus some special sauce), why should every brand have to build these capabilities?

3. Do brands really want to go from having their infrastructure managed to all the cost and complexity of managing it all?

4. Instead of every brand building integrations, UX components, features, and re-inventing the enterprise-integrated wheel, why not do a lot of the work and brands can focus on what's truly custom?

The more successful brands the more all boats are lifted and so we set out to make the move to scale easier. That's the last plug you'll get in this post, read on and then reach out if you'd like to learn more and I'd be glad to share and help decide what's best based on your brand journey (honestly, whether you choose Shopistry or not drop me a line and I'd be glad to chat at jh@shopistry.com).

The good, bad and ugly - what it really takes to evolve

We've worked with awesome brands growing from $20M to $250+ and just getting started. Our friends at Oura Ring were ahead of the game, embracing an integrated approach that removed limitations they were facing when the company really started to scale (because the product is fantastic). Product management flexibility, custom purchase flows, data manipulation, and an infrastructure that can handle crazy traffic all happened and that foundation continues to power the future.

Black Rifle Coffee's mobile app is another great example of a bespoke customer experience integrated with backend systems that really provides a unique customer experience. It's personal, engaging, and includes features you can't do on a web store to drive discovery and sales like push notifications, content and more. Engaging customers with new channels needs to be purposeful and well planned and it's always based on an integrated approach.

We've learned a lot of lessons on what it takes to evolve as your brand grows and I thought I'd share them here. At Shopistry, we took those lessons and others to shorten that lifecycle so brands can evolve to their optimal solution a lot faster and get on with growing

1. Application-based Stores vs. Themes because flexibility, performance, data matter

When my cousin asked me to build him a website I told him to use Wordpress, pick a theme and he'll be good to go. But inevitably when my cousin gets to a use case not handled by the theme he'll need a developer or an agency. Every brand you know at any measure of scale has an agency working in the background because that all-in-one platform can handle all use cases. And that's not a problem until the theme, code hacking, and restrictions make business goals hard or costly trying to fit a square peg into the round whole.

All the major platforms know they can't cover all bases and have APIs that let you build your own frontend applications and integrate with their backend admin. And that's when it gets tricky.

Web applications, built with modern and open technologies remove those restrictions because you can code the application to do whatever you want. Gmail, Facebook, Instagram, Slack, Netflix and every other

major software is a web application, mobile application, etc. The common technologies today are now referred to as the JAMStack and there are lots of frameworks to get started but it's not easy and also shifts more over to the brand to manage.

  1. Pick a framework or develop from scratch
  2. Integrate with APIs for your backend eComm admin
  3. Integrate all the other services you need (everything that was a plugin now needs an integration)
  4. Stand up a hosting account (AWS, GCP, Azure, etc.)
  5. Manage infrastructure, integrations, frontend, etc.

You'll learn a lot of lessons along the way, learn, rinse, repeat. In terms of cost and time you're looking at 6-8 months and $500K+ to launch, ongoing costs to keep the lights on; managing infrastructure, traffic and sales loads for peak times like Black Friday and sales. Our friends at Spiceology (damn good spices) also recognized that you'll need a dedicated in-house team (or agency) that really knows their stuff to keep on top of it all as new challenges along the headless journey are uncovered.

That's a huge lift when you're used to some other company providing and managing the tech while you're investing in growth. But, whether you're a squirrel or a brand, adapting for success isn't a necessity. Sorry, I think squirrels are fascinating :)

At this point you've wired up the providers and frameworks but now you need to create the actual experience customers will love. And you need to make it easy for your marketing and product teams to manage that experience. You need a content management system or your marketing, product, and tech teams might just revolt.

2. Content Management because you don't want a mutiny

Getting your own awesome storefront application is great and the tech team is excited. But your marketing team needs to be able to change content on your store pages, promotions, and you more on the fly. Without a CMS they have to ask the dev team to make changes in the actual code of your store. New promotional messaging? New image or text changes? New sections? You need to ask the developers to do it in the code which slows down time to market and makes everything harder to manage.

Our experience has been that once a storefront design is set, it doesn’t change every week. What does change is the content based on sales, promotions, new products, etc. and that can happen weekly or even daily based on business goals and opportunities. Together with the ability to publish blog content, 80% of what the marketing editorial team needs shouldn't require digging into code.

Headless CMS solutions are built to make this part of your life easier...but requires work. Shopify, Wordpress, Magento, etc. are all based on themes and you can change content in your theme editor/page builder of choice and that talks to your theme (before it all falls apart and you're dealing with custom code in your theme files!). But your awesome new high performance web store, mobile app, or bespoke shopping experiences isn't limited or controlled by a theme.

Modern content management to support dynamic experiences is all about the data and here's what it takes. Let's use a typical hero banner as an example:

  1. In your store code you need to build components that represent sections on the page. For example, your hero banner is a section and needs an image, title, subtext, and a CTA button ('Shop Now')
  2. Now in your headless CMS, you need to build data structures where you define the data that each component is expecting. So, for the hero banner you build a data structure with fields for the data that your front end code is expecting (image, title, subtext, CTA link, colors, alignment, etc.)
  3. Ok, now you have two pieces of the puzzle! When you publish that data is sent from your CMS to your store component and is rendered on the page.

What's great is that same data can be sent to a web store, mobile app, B2B portal, or any other shopping experience that needs a hero. Create and publish by channel or everywhere! It's very powerful, flexible and open vs. themes and page builders. At the beginning and when you'd like new sections or designs you'll need engineering to play a role and enable marketing to do what they do best. You'll also want to consider other capabilities like draft content, previewing, and content rights among your team. A/B testing, heatmap analysis, etc. are best done through Google Optimize, Optimizely or a similar tool that does this best.

So, that's what it takes to make life easier now and long term and at Shopistry we created a bunch of these components including dynamic components for displaying products and content, saving time and costs, and giving you a head start.

At this point you've got a great looking, flexible store where you can keep evolving the user experience without restrictions. Need to support multi-currency, countries, subscriptions, members areas? Want to run one store across multiple countries? Anything else? Just build the feature and manage the content. The last piece of the puzzle are all those mission critical analytics, marketing, payments, ERP and other services you need.

3. Integrations vs. Plugins because you can't grow without control

By their nature, plugins built for a specific backend are designed to work with the associated frontend; Shopify plugins are designed to work within Shopify themes.  Plugins (or Apps) made things easy but also restrict the user experience and operational control over certain aspects of your business like being able to directly manage transactions, fraud, etc. through the actual payment provider backend. When you move to an integrated solution, you can still use your eComm admin plugins to manage certain providers (like subscriptions) but your frontend customer experiences in many cases now need API integrations with those service providers instead. The more services needed, the more integration work which means time/effort and ongoing costs to implement and manage. We’ve found that although there are simple integrations that only need some JavaScript (JS) code implemented, there are many more that require API/SDK integrations to manage data flows. For example, implementing a marketing popup using Klayvio is as easy as adding a JS snippet to your site. But collecting commerce behavior and checkout data requires integration with Klayvio APIs to have that data flow back to Klayvio and be rendered and used appropriately for campaigns, etc.

Compared to loading plugins that are designed as 'one-size-fits-all', provide limited UX options and slow down the customer experience, the benefits of API integrations include much better performance and flexibility in the customer experience, data management, and speed. And that all matters for your precious SEO and traffic goals, even more-so with Google's new emphasis on mobile and core web vitals.

The challenge is that integrating multiple services is hard and rife with complications that you only discover after getting into the weeds and at that point there's no turning back.

Let's use a typical Shopify + ReCharge integration as an example where you'd like customers to be able to do more than just subscribe to a product. Instead you'd like your own dynamic subscription options and flows, subscription management, member only areas, and more. This might be on your web store or even better on a mobile app that gives users push notifications of new subscription options, updates, and other discovery and conversion drivers. Achieving the goals we described isn't what your typical ReCharge plugin implementation is designed for.

Here's what it looks like:

  • Integrate with the Shopify APIs for customer authentication, products, account information, billing
  • Integrate with ReCharge APIs for products, account management, billing
  • Managing user authentication across Shopify and ReCharge
  • Ensuring the user doesn’t need to login again when using Manage Subscriptions
  • Ensuring that what happens in the frontend is accurately captured and data relay to ReCharge and then Shopify
  • Keep up with changes from both Shopify and ReCharge as their approaches change (for example, now all subscription providers on Shopify go through Shopify Checkout)

ReCharge and Shopify are great together, it just requires more work to make it happen and stay on top of all your integrations.

In my mind, integrations are the heart of enterprise scale and growth. It's what this whole headless thing is about, and having a plan of action that is cost effective, seamless, and scalable matched with business goals is a must. Change is constant and your ability to add, remove, and succeed with the solution providers that work for you isn't debatable.

Wrapping it up (and squirrels)

We're just scratching the surface here and there's always more to unpack but I hope this post gives you a deeper understanding of the reality behind the buzzwords. The truth is continued success requires the ability to adapt, find new opportunities, and remove obstacles to deliver on your goals. At Shopistry, we're working to make that happen. Get in touch and look out for more content helping move you forward.

Until next time, enjoy the genius of squirrels!

Continue reading
Book a demo to try Shopistry headless commerce

Get the latest in modern commerce

Research, tips, and know-how to keep you ahead of the curve as commerce evolves.
By subscribing you agree to Shopistry's Privacy Policy, and you consent to receive marketing communications from Shopistry.