BigCommerce just hosted a twitter space titled “Headless E-commerce: Who needs it and who is better off without it?”  Lots of smart people were on the call (and me!) and a number of interesting points based on various experiences were raised. It also drifted into “Composable Commerce”. I did not start taking notes from the start, but here is what stood out to me. It ended up more interesting and thought provoking than I expected!

And sorry, I did not write down who made all of the statements or the exact wording. I was not planning to write a blog when I joined the call. But people on the call included @Filrakowski, @IsaiahBollinger @LoanLaux @kukovisuals @jcowie @sun_integration and @kerryhew.

Definition: Headless is where you build your own custom web frontend that talks to a commerce backend. For example, you decide to use VueStorefront or Next.js Commerce to build a storefront that hooks up to backend such as BigCommerce via API calls. This is done instead of using the storefront technology stack provided by platform.

First, some fun statements.

“Only 1% of sites need headless”

The claim was most ecommerce sites can make do without headless. A headless solution typically requires more development effort and maintenance costs. A company without a good technical team might be better to stay away. Most platforms have pretty powerful frontend tools that are well integrated and solve many problems for you. You really should have a specific need before going headless, not just do it because “I heard it was the latest cool thing from a friend”.

There are benefits to headless. Greater flexibility, less tie in to a backend, potentially better performance, etc. But it comes at a cost, so be sure the cost is worth it for your business.

“Headless is for $20M+ revenue commerce sites”

This could be a useful guide for sites. If you are a small business with small revenue, just skip the headless discussion. You probably are not going to make a profit going down that path.

“Headless can be useful when you hit 20 to 50 storefront extensions”

The point here was that the more shrink wrap extensions you add to your site, the greater the chance some integration between them will go wrong and you may lack the ability to clean it up. If you truly need them all (you truly need that complexity), then headless may become a necessity to give you the control you need. Does your loyalty point extension work with the optimized checkout flow extension? Do you really need a fraud detection system that monitors user behavior on the site before purchase? The probability of problems goes up as the number of extensions on your site increases. If you need all that complexity, you may need to adopt a headless approach.

“If Headless is for $20M sites, then Composable Commerce is for $100M sites”

Definition: Composable Commerce is the concept of combining best of breed technology verticals into your site. Pick the best tax solution for you needs, the best shipping cost calculator, the best loyalty points program, the best warehouse management system, etc. It is the dream of picking between alternative vendors for each sub-system and having them all just work. Platforms somewhat achieve this today by technology verticals providing platform specific extensions – e.g. a BigCommerce extension for ShipperHQ. In my opinion, the vision of composable commerce is to go further – don’t require technology verticals to build integrations with every ecommerce platform one by one to make it possible to build new ecommerce sites.

The point behind then $100M threshold was if you want to integrate multiple backend systems, expect real development costs, more than headless. Lots of system integration effort is potentially required. This led to the following statement.

“Composable commerce is really just enterprise architecture (we don’t need a new term!)”

Isaiah Bollinger made this point. He had a definite opinion that having a new term (“composable commerce”) is not helpful for merchants. It just makes things more confusing. It’s only relevant for larger (enterprise) companies as they are the only ones that can afford the costs that come with it. (He gave examples of ERP solutions where you might have one system maintaining the source of truth for product pricing, another system for loyalty programs, another system maintaining product details and images, and then your basic ecommerce site functionality of carts, payments, etc. You need to get these systems all working together.)

My opinions

It was a fun conversation. Things I left the call thinking about:

• “Headless” and “Composable Commerce” are technical terms that are now also used by marketing folks. Developers may understand the benefits of different technological approaches, but it does not always translate well to marketing and sales discussions. Not everyone needs headless. Not everyone needs Composable Commerce. Explaining the concepts can be hard to non-technical folks.
• Should everyone go headless? No. A part of me cringes using numbers like $20M revenue as a threshold for a business (its rather simplistic), but at the same time I like it as it does help smaller merchants to just skip the discussion of whether they need it.
• Headless can be more appropriate when you have multiple systems that are the sources of truth for their respective information, if existing platform integrations do not already exist.
• One topic not discussed was the benefit of being able to create smaller custom experiences. Do you want an in-store kiosk? Or do you want to make a specific product trivial to purchase during a social media campaign? If you platform has the capability to build headless solutions, you can more easily build small custom experiences for particular events.
• Is Composable Commerce truly new? If I get extensions from a platform’s extension marketplace to integrate with multiple SaaS providers for specific services, isn’t that Composable Commerce already? I think yes. But people talk about composable commerce for more extreme cases where the business model depends on integration of multiple systems that are not normally used together.
• Is Composable Commerce a useful term? I think the question is irrelevant. The term is out there and it will be used. I think the question is more whether it should be a major marketing selling point (and hopefully not the new snake oil of “the solution to all your problems”). I think it’s a useful term to make it clearer to merchants that they should not only be thinking about a platform to adopt, but also what other technology vertical specialists they should be establishing relationships with.
• Is Composable Commerce just Enterprise Architecture? Not in my mind, although I think that is the right audience to use the term today. Examples were brought up on the call where you want a middleware layer integrating different backend systems that can be accessed by your frontend. The frontend here may be headless as existing stacks might not cope with an extended backend. Smaller merchants don’t need to stress over terms like “composable commerce” today – they can just use “extension marketplace” or similar. So in my mind its more they don’t need to think about it rather than its not relevant.
• Why are Headless and Composable Commerce both used in the same sentence? I think it’s because, today, an advanced Composable Commerce solution is likely to need something beyond a simple platform-based frontend. It will probably need a custom build, which is what Headless is. So today, both are often used at the same time, but they are different things.

But I will end with my ivory tower desire. Let me build an ecommerce solution by having multiple vendor choices for each of the system components. Merchants can pick which ones to use in their solution, picking one with the capabilities that best meets their need. Make this feasible for smaller merchants, not just enterprise-level merchants, beyond just platform extensions.

Will this ever happen? My guess is for the pure vision, no. It is based on the core platform being an integration platform, not providing much functionality itself. Where is the money for the platform in that? Also, I don’t see all vendors agreeing on a consistent data model for all concepts (What goes in a shipping address? What is a customer profile?), so integrations are going to be required to deal with differences in data models. That does not mean it’s not a useful concept or vision to move towards, products on the market will help it become more achievable, but be realistic.

To wrap up, terms like Headless and Composable Commerce are not new architectural concepts: custom websites (headless) are not a new concept; integrating different systems (Composable Commerce) is not a new concept. They are just terms to help succinctly share concepts and architectural patterns… assuming the rest of the audience shares the same definition! I still have the hope to get more of the advanced tools in the hands of smaller merchants.

Want more like this? You might like to follow @BigCommerceDevs to hear about upcoming discussions. (I am not affiliated with BigCommerce, I just happened to join the call!)