Benefits of headless for eCommerce

Headless architecture is a modern way of writing websites that doesn’t require databases. If the template code is the head and the database is the body, we only care about the head. Hence, headless. This is also known as the “JAM” (Javascript, API’s, Markup) stack. Does this mean it should instead be called Bodiless? Perhaps. But this is the Internet. We do what we want.

Benefits of headless for eCommerce

Hello, this is not Tim, this is Love and Money, and we’ve co-opted 1-800-D2C to tell you a thing or two about Headless. If you wanna know about us, click here, if you wanna get into some serious nerd shit that’ll make your website fire, read on, breh.

Usually Tim tells you about tools and stuff, we love that. We use them too, but we often make ‘em work with a Headless stack which is a bit of a different game. So we wrote this piece called: “Headless for eCommerce” for y’all. We’ve used Headless for heaps of projects that we’re pretty proud of (we see you Karst Stone Paper, Nopeet, Hereafter Let’s dive in!

What is Headless?

Headless architecture is a modern way of writing websites that doesn’t require databases. If the template code is the head and the database is the body, we only care about the head. Hence, headless. This is also known as the “JAM” (Javascript, API’s, Markup) stack. Does this mean it should instead be called Bodiless? Perhaps. But this is the Internet. We do what we want.

It’s like a chicken with its head cut off that continues to run around – forever. But instead, imagine it’s the head of the chicken running around. And it’s more powerful than it was with legs. Because it’s rolling down a hill, and when chicken heads roll without legs, they actually go faster. Don’t get us started on where we stand on the egg. The egg’s not here right now. It’s an analogy.

Before we get too nerdy, here are 8 reasons why you might want to go headless...

1. It’s speedy, AF

  • More efficiency in writing codes
  • You’re only making changes to the front end.
  • Continuous Integration and Deployment is faster, too.

2. It plays nicely with others.

  • API approach is faster and more seamless to integrate into other systems

3. It’s got better stats. 

  • Page loads faster
  • Website conversion drops by 4.42% with each second of load time
  • Bounce rates increase by 32% percent as page load time increases from 1 to 3 seconds

4. The customer will like it, too!

  • No page refreshing
  • App-like experience

5. You’ll feel like you’ve got more flex (even if Zuck maintains a firm grasp on your neck).

  • You can try out new vendors, tools, features and functionalities
  • Bespoke UI
  • Faster and more responsive to user needs
  • Integration compatibility with more channels, like social media (Instagram, TikTok, Facebook, etc.)

6. It looks hot in the front.

  • Personalisation of customer experience with different eComs, CMS, presentation

7. It’s a party in the back(end).

  • You get to choose what frameworks that you want to use (React, Gatsby, Next, Vue, Nuxt, Angular etc...). Any technologies, UI frameworks or Architecture.
  • The only restrictions are from the APIs and Microservices you get from the vendors you choose.
  • Immense power/ value to have the ability to choose.
  • Advantage in having the knowledge on the latest technologies.
  • More fun for developers.

8. It’s ready for 2030.

  • Continually improve/update your eComms system
  • Ability to adapt to changes in technology

A badass Product Detail Page - all headless tech

The stock standard traditional approach to making a website was to use monolithic architecture where your front and back end were tightly coupled together on the same platform. Your database and website would all live on the same server. You’d probably even manage the content and styling of your website there as well, using only one login and admin panel.

A good example of monolithic architecture is Shopify. It’s a one-and-done. You log in, add products, change your website theme, edit a bit of text on your home page, install a reviews app, all without leaving the admin panel, which can be useful. But only to a point. It ultimately means you’re limited to what the platform wants you to do. Because Shopify’s focus is more about everything that happens from the checkout onwards (there’s a lot of work that goes into making sure payments work seamlessly across different credit cards, across the world, and then even more work that goes into making sure the technology seamless integrates with the 3rd party tools and services that make sure your vegan hair products are actually shipped to your door) they spend less time than other dev teams on creating amazing front-end tech. Makes sense; their customer is the D2C customer, because they know a happy D2C customer will demand that their in-house team or agency use their platform, no matter what. So if you want the great back-end stuff that makes a D2C business owner’s life easier and literally richer, you’ve gotta put up with the sub-par front end stuff that makes for slow page loads and crappy integrations. Not so with headless.

“Orroit guv’nor, so what in the bloody ‘ell is ‘eadless?“

We’re at the bit where you find out, clam down ol’ mate Joe (inside joke).

Because the JAMstack doesn’t require a database to run around, it can be hosted anywhere, built with any language, library or framework of your choosing (React, Vue and Angular to name a few). And because there’s no one proprietary database that the JAMstack has invested in, headless technology is more agnostic when it comes to integrating with other databases, or other tech stacks purely for their databases, without having all the other faff that comes with them.

Imagine you want to cook a curry, and you’d like to include cashew nuts because they’re delicious. What would you rather use? A handful of roasted cashews? Or a block of Cadbury cashew chocolate? Both have what you want, but chucking chocolate in your kaeng khiao wan just to get to the cashews is gonna make for a pretty shitty user experience. What you want is either a) some sort of technology that gets rid of all the chocolate and exposes only the cashews, or b) some cashews that never flirted with the dark stuff in the first place. 

That’s what the “A” in JAM stands for: API, or “Application Program Interface”. Integration is basically JAMstack’s middle name.

Going back to the Shopify example: the actual website itself is no longer hosted on Shopify’s servers, so now your front end needs to grab data about your store from Shopify (products, skus, images, stock/ inventory). This is done through RESTful API calls. Shopify knows it sucks at front end stuff (and as such is heavily investing in Headless tech — see Hydrogen) so ensures it has a StorefrontAPI which exposes the data you need for your online store.

Page Layout data points pulled via RESTful API calls


With Shopify staying in its (Ecommerce) lane, we are free to ask other services other questions for other needs. Just like Shopify is amazing at making the tricky part of payments and logistics seem effortless, other tech products are similarly single-minded, and all the better as a result. You could, for example, use a CMS like Sanity to manage all of your front-facing site content and data, Netlify for hosting, Algolia for product search functionality, Stamped for reviews on Products, and then Gatsby.js to tie it all together. Shopify remains our go-to for handling checkouts and customer logic. If for whatever reason we needed to decommission Shopify as our Ecommerce provider, we’re free to remove and replace with something else, without affecting the look, feel and functionality of our headless build.

Something to keep in mind when looking at your technical architecture is the role of connected plugins, apps and libraries. Shopify offers some internal applications for data management, like reviews (e.g. Stamped, Yotpo) which may not work in their default manner when introduced into a headless stack. When dealing with one of these so called “Microservices”, a key question is raised: do we attempt to bring that data straight into our headless app - in the same way a ‘normal’ website would - or do we allow the Microservice to exist where it ‘wants’ to, and attempt to transform the data later?

Headless Yotpo
Hereafter - Using YotPo reviews


In our opinion, something like Stamped that requires a link with Shopify data belongs in Shopify. We’ll ask Shopify for info on how that’s working. However, something like Google Tag Manager, which has a sort of global context, belongs above Shopify, and should not be funnelled through it.

Downsides you ask? Well one is that you do need to know how to code. You need to know how to make the API calls, and how to integrate that data into your front-end. There is no WYSIWYG editor, or drag and drop page builder.

To manage our content, a CMS we prefer to use is Sanity.io. Mainly for its simplicity and flexibility. It also gives our clients the ability to build out custom pages with predefined and designed page sections from us. So for our clients, it's almost like having a WYSIWYG editor a la Wordpress, but we get the extra benefits of having a high-performance, modern Headless site.

So, why would you go Headless? Flexibility, and risk aversion. Headless affords you the opportunity to choose the tech for your website, and protects you from changes to interconnected services.

That’s it from us, if you’re interested in Headless get at our inbox. We also write a dope newsletter of our own where we go deep on topics like this, share tools, resources and the like, subscribe to here.