Acquia Drupal + BigCommerce: Should You Go Headless or Side-by-Side?

We’ve outlined why we are confident that Acquia + BigCommerce will succeed in developing a content + commerce platform that actually works. Having a unified platform that excels in both areas will be a gamechanger for many companies.

But this is just half the battle. The most crucial decision to success or failure is how the experience is architected for the customer journey. To truly achieve success, organizations must wisely choose the best integration approach, headless or side-by-side.

If you don’t, you’ll likely incur massive interest payments on technical debt that would make the US deficit seem quaint by comparison.

Before we can talk about how to choose the best approach to content and commerce for your organization, we have to fully understand and accept the serious limitations that exist with one of the two major approaches. This limitation is not fatal, but failing to be honest about the implications of this is a quick path to project failure for organizations.

The limitation of headless that will cost you if you ignore it

There are two major approaches to combining content and commerce: headless and side-by-side.

Headless: Broadly, in a headless approach your content platform (e.g. Drupal) serves every experience to the customer, including a content page, search, collection pages, my account, the product detail page (PDP), cart, and checkout. The commerce platform is headless, meaning it does not serve any front end experiences but interacts with the content and customer layer via APIs.

Side-by-side: In a side-by-side approach both the content and commerce layer serve different parts of the customer experience. The specific experiences provided by each platform can vary in your implementation, but typically in a side-by-side approach the commerce platform serves the collections, cart, checkout, and PDP experiences, and the content experience provides the others pages.

This table details the experience breakdown. The side-by-side approach has some variety in which specific experiences are served by what platform, but the headless platform essentially does not vary from the below:  

In the scope of our discussion, we are only talking about browse and buy commerce experiences. A browse and buy commerce experience is the most common form of digital buying, where customers browse a collection of SKUs, add multiple items to a cart, visit lots of different pages, potentially apply a discount, and checkout. What are the less common experiences? Think about buying a concert ticket (picking the seat, section, date, venue, pricing, etc) or making in-app purchases in a native mobile app. These are big parts of digital buying, but they aren’t browse and buy.

So, what is the crucial limitation?

Well, it all goes back to understanding that in browse and buy commerce experiences, commerce is not a feature, it’s a platform. Commerce is hard. Like, really really hard. You have all the same challenges that content does—rendering a clean theme, SEO, integrating with marketing technology platforms, languages—plus more integrations (think ERP, finance, CRM, email), promotions (the more you work with promotions the more respect you have for the obscene complexity here), taking money from people, and fulfilling the actual order.

It all comes down to the product details page. The complexity of commerce means that there are many extensions, plugins, and integrations managing all of that complexity in the commerce platform that all believe the commerce platform is rendering the PDP page. In a headless approach, the PDP is being rendered by the content system which means most, if not all, of those extensions are now broken and have to be refined—or rebuilt wholesale—to work in the content layer.

It’s like buying a gas Ford truck, ripping out the engine after purchase and installing an electric engine, and assuming that all of the dashboard instrumentation will “just work”. Spoiler alert: You might still be tough but you certainly aren’t going anywhere.

This is the limitation that so many organizations miss, or fail to take seriously, in their analysis of what approach to take. It’s not fatal, there are reasons to go headless (we will discuss those in the next section), but organizations must be realistic about the implications of this.

How to choose: side-by-side or headless

To determine if you should go headless or side-by-side, first ask yourself this question: Are we creating a primarily content experience, a primarily commerce experience, or both robustly? (And if you’re not sure what to build, read this).

These questions will help you identify what you are really creating:

• If you asked the team, would they say they are a building a content site or a store?

• If you could only do one thing, would it be content or commerce? What about in three years?

• Do you use promotions?

• Are you browse or buy, or something else?

• What is the SKU count?

• What is the search experience like?

• What is the biggest problem you are trying to solve in the next 24 months?

• What are your two or three goals?

• How large is the digital merchandising team? How large is the marketing team?

• Which budget would be cut first: content marketing or commerce marketing?

The answers to these questions should get everyone aligned about what are the characteristics of what is really being built. For deciding headless versus side-by-side, here is what the three typical use case characteristics look like:

Try mapping this all out on a whiteboard in a meeting with various stakeholders. The answer will become self-evident.

Once you go through this exercise the right approach is pretty clear

If you are more a content site, go headless. The friction of having to rebuild what extensions provide to the PDP will be worth the effort to manage a single theme layer and front end system. As a bonus, a firewall can be used to block all traffic to your commerce platform except from your store. Or, you can use the commerce platform for the cart and checkout, and minimize the investment in maintaining two themes (cart and checkout should probably use a reduced theme anyway to improve conversion).

If you are more a commerce site, go side-by-side. Sure, you will have to manage two theme layers but that will be less work than trying to rebuild all of the functionality the commerce platform and plugin ecosystem system provide to the PDP, cart, and checkout.

If you truly need both a robust content platform and a robust commerce platform, go side-by-side. This should be clear by now. If not, tread carefully!