Devin Saxon spends much of his day having in-depth conversations with technical decision makers about whether or not headless commerce is right for their eCommerce brand. As Nacelle’s Senior Sales Engineer, he’s an expert on the decisions engineers have to make about headless commerce and the pain points they need to solve for.
We caught up with Devin to talk about the most common concerns and questions CTOs and technical buyers have when thinking about implementing a headless commerce solution. Here are the most common questions Devin gets asked, and his answers.
1. Do merchants need a headless commerce platform, or can they build a solution in-house?
First, let me say that the eCommerce brands we talk to about "building or buying" a headless system have incredibly talented engineers on their teams who are capable of building almost anything. That said, most want to spend their time and resources building systems that will differentiate their brand and give them a competitive advantage.
Additionally, the scope and resources needed for an in-house headless build—including maintenance—are almost always underestimated and the project is usually more costly than anticipated.
The decision around whether or not to outsource a headless build also typically includes conversations about data velocity. One of the most overlooked (yet most important) aspects of a headless commerce solution is the ability to flow data into systems at a high velocity. Without that functionality, merchants will face scalability issues. And because this often gets overlooked in the "build vs. buy" debate, it’s a sneaky yet crucial factor when weighing your options because it significantly impacts the scope of your build.
API rate limits, poorly designed APIs, and slow API response times will cause bottlenecks in data flow. For instance, when you tie your PIM and CMS directly to your progressive web application, each solution has their own API rate limits. Not only do they have to communicate with the frontend, but they have to communicate with one another, and it leaves a lot of opportunity for bottlenecks.
That puts pressure on your dev team to maintain those various APIs. Part of what makes a headless commerce platform like Nacelle an attractive option for merchants is that it consolidates everything down to one API, which makes it super clean and scalable for developers. Additionally, those bottlenecks are eliminated because Nacelle acts as a layer of abstraction, and has an elastic core that can scale horizontally in milliseconds to handle large bursts of API calls needed for your frontend build.
2. Are there any headless commerce benefits besides site performance?
Yes! There are strong benefits around development that aren’t talked about enough. Of course you’ll ideally see big site performance gains with a headless progressive web app, and static generation. But along with that, your dev team will only have one codebase to manage. One codebase across devices helps online retailers focus their energy on mobile-first, which is necessary for eCommerce success today.
Developers can also take advantage of Git Push for the development cycle, which is great because it allows them to work out of a codebase that the entire team has access to. When one person makes an update to that codebase, everyone is on the same page. And when it comes to pushing things to production, it’s really easy and safe.
It’s a big win for developers to have all the resources they need on their own computer without worrying about messing things up that are in production. They also have the ability to QA like never before. Because the improvements to developer workflow streamline resources, it also frees up time to focus on those differentiating projects I mentioned earlier.
3. How can headless commerce help merchants scale and be responsive to change?
The best way to be agile is to set your tech stack up in a way that prevents vendor lock-in. You can do that with a microservices, best-of-breed approach. With a best-of-breed tech stack, you can either build or buy the best solutions available in their respective areas, be it a PIM, CMS, OMS, eCommerce platform, etc.
The right headless commerce solution will act as the “connective tissue” for these disparate systems. It will unify syntax and support high data velocity between systems.
When you outgrow a tool, need to make a change, or want to add or delete a solution, this approach will make it much easier to do so. These systems are not hardcoded, and in the case of Nacelle, as you change services in your backend you only need to worry about connecting to one place—your data layer.
4. Why wouldn’t merchants want an end-to-end headless commerce solution?
This answer to this question is also rooted in the benefits of a best-of-breed microservices approach. To reiterate, there’s a lot of power in being able to cherry pick the best tools in their respective areas, regardless of whether or not you build them or buy them off-the-shelf from a top vendor. And when one isn’t working for you anymore, it’s relatively easy to add, subtract, or replace tools.
I encourage people to think about the definition of headless commerce—it’s a separation between your backend and frontend systems. An agnostic architecture will allow you to plug in whatever tools you need at the time in order to meet your business needs. End-to-end is another way of saying all-in-one. All-in-one is not tool agnostic.
When a headless commerce solution has a strong opinion on what your backend components should be, such as your PIM or CMS, it’s contradictory to the spirit of what headless commerce really is—a separation.
Some headless solutions even want you to use their complementary systems, which is locking you into an all-or-nothing tech stack. Now if you want to change any aspect of your tech stack, you’re looking at a full migration, which could lead to technical debt and data loss. Beware of those dependencies, they could be costly and change the integrity of your headless build.
5. How do you justify the price of a headless commerce solution?
This comes back to the "build vs. buy" conversation, technical debt, and surprise costs. The costs in the long run of building a headless solution in-house usually outweigh the cost of buying a service that’s already available to you, with engineers and teams maintaining it for you. Unless building in-house is going to offer you some differentiating aspect that’s not available to other brands, it likely isn’t where you want to channel your resources.
Also keep in mind that if conversation rates are improving by 20% to 30%, as it has for many of our merchants—or even 5% to 10%—that’s going to be a significant return on investment.
With a microservices approach especially, you’re enabling your brand to be extremely agile with your costs. In the long run, the cost of buying a top headless solution is money in your pocket that you might not realize today.
Have more questions about headless commerce? Connect with Devin or another one of our headless commerce experts to talk further.