If there was a headless build tally in the industry, our CEO Brian Anderson would top the list. Between his Shopify Plus agency days and his work at Nacelle, he has been associated with over 20 headless commerce builds and counting.
He’ll be the first to tell you that the reason he knows how to do headless commerce the right way, is because he tried all of the wrong ways first.
We got him to spill the beans on the trials and tribulations behind building a headless commerce solution—here are his answers.
Brian Anderson: The Shopify Plus ecosystem is strong and there’s a lot of momentum behind it. When you go headless you want to pick a platform that has a lot of integrations, or at least expertise on how to optimize your stack and integrate the Shopify Plus tools that you use. You want to go headless, but you don’t want to lose the value of the ecosystem.
When I first got into headless commerce, I was running a Shopify Plus agency and our clients were coming to us describing a particular pain point around page load speed. It came at a time when more and more traffic was coming from mobile devices as opposed to desktop. We realized then that this was revolutionary in the way that people shop online.
Prior to this point, people thought shoppers weren't comfortable breaking out their credit card to buy an expensive purchase on their phone, but that feeling really diminished. This was also during the advent of performance marketing, where people started buying through ads on Instagram, Facebook, and Google Mobile.
Merchants started to see this overwhelming amount of mobile traffic. Slow page load speed is annoying on desktop, but infuriating on a mobile phone.
We didn't call it headless commerce at the time, but we were trying to replace the part of the tech stack that wasn't working well. In our world, that was the frontend, and we naturally went down the path of decoupling the site’s frontend and the backend, which is the definition of headless commerce.
We realized that if we separated the frontend and backend the right way, we could unlock a lot of value and build a mobile solution that was just as powerful as a native app—without forcing customers to download anything on their phone. This in combination with Shopify’s checkout technology, Shopify Pay, makes for a very robust solution.
Brian Anderson: In order to have a good frontend, you need an extremely performant backend. This is a paradigm shift.
If you’re using technology on the frontend to execute a great shopping experience—things like Vue and React—and doing it right, with advanced techniques like static generation and single page application, you’ll see the most conversion rate gains. All merchants are after that.
In order to satisfy the requirement of single page applications and static generation, you need the ability to do a massive amount of queries within a very short period of time. You'll have to query multiple APIs, such as Shopify Plus and the CMS you choose, if you're not using a backend like Nacelle.
The first mistake we made at the agency was trying to do many queries against many disparate systems, all at once. It was a mess to pull that data efficiently.
If that’s not happening, your frontend and your backend are not going to be consistent. There's going to be a discrepancy between what's appearing to shoppers on your Shopify Plus storefront, what's going on in your content management system (CMS), and what's actually happening when you’re statically generating.
We quickly realized we needed a backend solution in order to support these frontend technologies that help enable the best shopping experience.
The first few headless builds we did worked really well for our merchants, but there were so many challenges to overcome. In the process of doing over 20 headless builds, we’ve learned so much about what works and how to navigate the headless environment on Shopify Plus.
Brian Anderson: Yes, when we realized how much time it took to build a backend data layer for each client individually. We realized there was just no way to sustain that. We’d have to bill $2 to $3 million just as a starting point—minimum—to get it right. And that wouldn’t include maintenance or upgrades.
We realized that a lot of other folks will have this problem too. Building a system that was multi-tenant with one big, strong, scalable architecture was key. Our architecture had to be elastic, which means many merchants sending thousands and thousands of requests a minute without affecting performance in any way. We knew a SaaS business model would be a much better match than an agency model.
Brian Anderson: First and foremost, you have to understand that headless is not just an app you're installing. It's not just something on the frontend that's a little widget.
This is a change to your business. It affects the shopping experience and how you merchandise your store. It affects content modeling and how you drag and drop to move items around on the page. Sure, we can give you drag and drop functionality, but does your merchandising team understand the new way of approaching changes and how to build landing pages? It will be different.
Your brand needs to be big enough where this is going to be a no brainer for ROI. We’ve found that it becomes really relevant at $25 million GMV and up. Anything less than that and maybe you're focusing on the wrong thing. You want to make sure you have strong product market fit before you make this move. You should also be willing to invest in engineering, whether that means bringing people in-house or working with an agency.
For merchants that are right, the ROI is monumental. For instance, our Barefoot Dreams case study—64% improvement in conversion rate and we have others in the 20% to 30% range.
The ROI just on conversion rate alone is immensely compelling. Also, when you start to realize that you can merchandise faster and build landing pages that convert faster, the door opens to other second- and third-level benefits that really help you and your team.
Brian Anderson: When I started this endeavor in the agency world, merchants realized that this was an essential part of what they do every day. So, they were a little leery about letting us just build out a custom stack because they didn't want to feel locked into an agency.
The truth I learned about agencies after doing it for years is that people leave. People come, people go, and sometimes they’re key people with tribal knowledge about your codebase. Suddenly when a key person leaves, there's a lot of knowledge about your custom codebase that's lost too. I really recommend that merchants use a platform to solve this problem as opposed to custom code.
A lot of other companies out there claim to be headless, yet they have an opinion on what CMS or PIM you need to use, or worse, they force you to register content management components that are specific to their solution into your frontend framework—which means it’s not actually headless. It creates a hard dependency between your backend and your frontend, and therefore it’s not decoupled.
If you're going to do the work to go headless, we highly recommend that you stay headless and don't experience vendor lock-in during the process. We’re anti rip and replace. We want to work with what you have and that’s an important aspect of going headless.
Brian Anderson: The most important thing is that you have a strong data layer in place. That data layer is aggregating everything on the backend including your PIM, CMS, and OMS. If you're using something like Shopify Plus—fantastic, but you're probably going to want to pair it with a headless CMS, so you're still going to have the issue of joining and merging disparate data sources together into one. Don't make your build more complicated than it needs to be by calling all these different APIs in order to do your static builds and PWA builds.
Choosing an API that's immensely robust so you don't have rate limit issues is also going to be important. It ensures you're getting the right data to your customers on the frontend. This is one of those issues where if your technical team is looking at the APIs from your stack it looks like you can pull this off and it will work, but it’s deceiving.
An analogy we like to use here is that it looks like you can build Twitter in an hour—it’s just a form with 160 characters. Of course, it would never scale the right way. Understand that there is a certain amount of data you will need to flow into your frontend at a very rapid pace. If you don’t get that right, your effort will be in vain. And it’s tricky too, because you don’t realize it until you go into production.
Implementation details like content modeling are also important. Understanding that yes, you’re getting a powerful content solution—Contentful, Strapi, Sanity, or another great CMS—but if your merchandising team and your marketing team aren't taking the time to sit down and flesh out how it’s going to be used, and what components you need to build on the frontend, it won’t be successful. If that work isn't done up front, and isn't done well, you're not going to have a good headless build regardless.
Of all the headless commerce builds that I’ve been involved with, that’s probably the number one implementation detail after the data layer that turns a build sour.
The third thing that's relevant are the apps and app integrations. You’ll want to do an app audit so you can understand what will work well in a headless world. Truthfully, different apps have different levels of APIs and different levels of JavaScript SDKs. Some just work better in the headless landscape than others.
Brian Anderson: I think it’s twofold. First, we’re a backend data layer that supports the frontend framework. We understand that in a world of PWAs you need to get a lot of data in a short period of time.
Our solution is built around elastic technology, it can scale up in milliseconds. Having that available to developers, not worrying about infrastructure, not needing a big DevOps team to get those capabilities—that’s the number one differentiator.
Number two, is this idea that we’re not the CMS, PIM, checkout system, etc. We have no opinion on these. We combine data from disparate systems and we join it together in one API. This is great because developers on the frontend only have to call one API or SDK.
Next Q&A: 2021 eCommerce Trends With Nacelle CEO Brian Anderson