In recent years, SaaS companies have been working to encapsulate “headless” while agencies have been working on ways to implement reusability and standardization in their respective delivery workflows. Understanding nuanced approaches and different options available is paramount when making the move to headless, because headless isn’t just a one-and-done project, it’s a long-term investment that requires careful consideration and foresight.

If this decision feels a bit overwhelming, reach out to our team and we will figure it out together. Until then, keep reading to understand the headless commerce landscape and the most important things to consider when selecting a headless vendor.

Before selecting your headless provider, ask yourself if headless makes sense for your business. Do you fit one of the four common headless use cases? Learn more in our article: Understanding Headless Commerce & Its Use Cases. Have you weighed the pros and cons of choosing a headless architecture? Check out our article: The Gains & Losses of a Headless Architecture. If none of those things are relevant to your business today, will they be relevant in 3-5 years? Do you see your direct-to-consumer or B2B business evolving in those 3-5 years where you might need near-infinite flexibility?

If you answered yes to any of those questions, then keep reading.

Before we get ahead of ourselves, let’s define a few key terms:

Headless architecture is a software development concept that decouples the frontend (user interface) from the backend (operations) layer of the website. But headless is just that, a concept, and there are many different ways to approach it.

For example, composable commerce is a headless approach that gives eCommerce brands the freedom to choose the ideal set of technologies and combine them into a unique composition that suits their business requirements and/or existing operational infrastructure.

We asked Dan Hill, SVP of Engineering, for his favorite analogy: “I like to draw the comparison that buying into a non-headless architecture is like buying an Apple computer. You get what you get and that’s all that you get. You can’t upgrade memory. You can’t change the hard drive. What you buy is what you get. However, headless architecture is like building your own PC. It will always run Windows, but you can swap out any of the hardware components at any time to facilitate a change in its purpose or use case. The PC build is composable. The Apple computer is static. Side note: Macs are awesome. This is a functional comparison, not a value comparison.”

Every headless architecture is made up of a head, a body, and a neck. The head is the storefront (what your customers see). The body is the e-commerce platform (back office, infrastructure, operations, catalog, etc). The neck is the conduit that connects those things together and lets them talk to each other. One could take this analogy even further. The head has eyes, nose, ears, mouth – these would be your storefront 3rd party integrations (CMS, reviews, UGC, product configurators, etc) and the body has arms, legs, fingers, and toes – these would be your 3rd party back-office and operational integrations (OMS, PIM, ERP, ESP, CSM, etc). In a TRUE composable commerce or headless architecture, all of these parts are interchangeable.

A headless framework is software you can buy to connect all your systems together and enable a headless experience.

How much freedom are you looking for?

As mentioned above, there are different approaches to headless. Most eCommerce vendors/platforms have elected to create a body, a head, and a neck – all under one roof while still satisfying the allure of “headless”, while others have adopted a composable commerce approach, focusing in on one of the three – which allows for the full decoupling of storefront (head) and back-office/commerce operations (body) to build a more custom tech stack based on one’s specific needs (i.e. a Vue Storefront and CommerceTools combo).

Why this matters: If you decide to choose a “one-roof” solution, you are theoretically locked-in with that specific vendor and very much at the mercy of their roadmap. Sometimes that can be a good thing. If building a custom tech stack isn’t a requirement or fiscal possibility for your business, then this approach will most likely be the right fit. However, if you want – or your business requires – the freedom to mix and match different vendors and connect them together, leaving yourself open for future upgrades/enhancements/vendor changes, then a composable commerce approach is the way to go.

How much will it cost to move to a different eCommerce platform?

One of the many benefits of headless (along with a long-term upgrade / extensibility methodology) is that, when done correctly, it eliminates any future need for full replatforming. If you’ve had to migrate from a legacy platform, you know how expensive and time consuming replatforming can be. This is what we call vendor lock-in. When selecting your headless framework or methodology, make sure to ask what will happen if you want to migrate to a different eCommerce platform. Many eCommerce platforms tightly couple frontend hosting and storefront (the head) with the backend and services layers (i.e. Magento). So will you have to rebuild your storefront and middleware/translation layer (neck) from scratch or will you just need to point your middleware to a new platform and continue using the storefront you have?

Why this matters: If you are investing a significant amount of time and money in a headless build, the platform you select should give you more freedom, not less. Otherwise, you may miss out on the largest benefit of a headless architecture. Building another headless site from scratch (new Apple computer) would be significantly more expensive than building just some parts (upgrading the memory on a PC).

How easy will it be to build on top of the framework or benefit from existing functionalities and integrations?

Most headless frameworks are only 1-3 years old, which means that early adopters might have to wait for functionalities and integrations or build them from scratch if they aren’t currently available to the public. Shopify is famous for their vast and convenient app marketplace, but their library of apps isn’t completely API-enabled and doesn’t translate to headless (yet).

Why this matters: Are you ready to foot the bill for building new functionalities and integrations? If not, you might want to consider a headless provider with the most complete solution or one with a library of reusable components.

Even if you have a development team in house, you will most likely want to hire an agency to handle your move to headless. Not only will this project require a team’s complete and undivided attention, it’s also always a good idea to work with developers who have experience in a specific language and platform and have developed a methodology around standardization, reusability, and future upgrades.

When researching different agencies, consider experience, but also their approach to building websites. The most important question is whether or not the headless provider or agency uses reusable components, and the protocol they’ve adopted or created to maintain that system of reusability without the introduction of technical debt.

What are reusable components? Code reusability is a practice from the earliest days of programming. It allows programmers to reuse selections of code, templates, functions and procedures to decrease the time and effort of software development. As a result, reusing components not only saves the client money, it can also increase the quality of the end product itself, as more time is spent solving problems instead of building the same things over and over again.

Why this matters: Another benefit of using a headless architecture is the ability to reduce technical debt. Over the years, the more developers work on your website, the more likely you are to accumulate technical debt, which not only dampens your site performance, it can also get in the way of future additions and optimization of your website. Having a library of reusable components and code isn’t enough. There needs to be a standard and a process by which that library evolves and is supported.

What to look for: Look for an agency that has experience with reusable components, has built an extensible library of options to choose from, has made the components within that library highly configurable, and has formulated an opinion and a process around how those components will be upgraded. The agency should also have a strong opinion about how valuable features and components can be cross-pollinated between implementations and has a thorough understanding of how their solution upgrades over time.