Headless ecommerce: when is it worth it?

Headless commerce sounds like a technical choice, but it is mainly about ownership. You take the store out of your platform's theme and build the front end yourself. That gives you freedom, and it also gives you a piece of software you maintain yourself from then on.

What is a headless online store?

In a standard online store, the platform provides both the shopping cart and the pages you see. With headless, the platform keeps the orders, products, payments and stock, but the front end comes from a separate application that fetches the data.

So the division of work stays: the platform does what it is good at, you handle the presentation. What that split looks like in practice is covered under Shopify Plus.

Headless, then, isn't a different store system but a different place where the pages are built. Everything behind the scenes, from stock to payment, stays where it was.

What do you gain?

• Front-end freedom: you aren't limited to what the theme allows, and an unusual flow doesn't have to be held together with plugins.
• Speed: you decide what is built per page and when, instead of running a theme full of third-party scripts.
• Multiple channels: the same products can feed an online store, an app and an in-store screen system.
• Content and commerce together: editorial content in its own system, products from the platform, on the same page. Strapi is a popular choice for that.

What does it cost extra?

Two things. The first is the build: everything the theme gave you for free, from search filters to the checkout screen, now has to be designed and built. The second is maintenance: that front end is your software, with updates, security and a partner who knows it.

There is a third that rarely gets mentioned. Apps from your platform's app store don't automatically work, because they were made for the theme. Every app you use has to be assessed again.

Calculate those three costs over several years, not just the year of the build. A front end nobody maintains is slower and less secure after two years than the theme it replaced.

Question 1: are you really stuck with the theme?

Write down three things you can't do now that your customers would notice. Not what your marketer would like, but what demonstrably costs orders or creates work.

If you can't write those three down, headless is currently a solution without a problem. Much of what people blame on their theme can be solved within the platform, as described in having a professional online store built.

A good test: what would happen if you didn't touch the theme for a year? If the store keeps selling, your bottleneck isn't the front end.

Question 2: do you have more than one front end?

Headless pays for itself fastest when the same data has to appear in several places. An online store and an app, a Dutch and a German store with their own content, or a showroom screen showing the same stock.

With a single online store in a single market, the benefits are smaller and the costs are the same. Then the question is whether question 3 makes up for it.

Question 3: is speed demonstrably your bottleneck?

Measure before you decide anything. Look at load time on mobile, the share of visitors who leave before the page appears and the difference between your category pages and your product pages.

If the cause is a pile of third-party scripts, headless won't fix it: those scripts simply move with you. If the cause is the theme itself, there are gains to be made. What a custom front end involves technically is covered under Next.js development.

Where does headless go wrong?

Usually at checkout. Your platform's checkout is rigorously tested and handles payments, fraud checks and taxes. Rebuilding it yourself is a risk that rarely pays off. Leave checkout with the platform.

The second pitfall is editing. Without a well set-up content system, marketing suddenly can't change a banner without a developer. Then you have gained speed and lost agility.

The third is search visibility. A custom front end can rank very well, but only if you carry over the URLs, the redirects and the structured data when you switch. That work is often left out of the plan.

When shouldn't you do it?

When your team is small and there is no partner to maintain the front end on an ongoing basis. When most of your revenue comes from a single channel. And when your platform will be replaced within a year: don't build a front end on something that is going away.

The same trade-off as in custom software or off-the-shelf applies here: buy what is standard, build only what is distinctive.

What is the sensible intermediate step?

Start with one part. Move only your category and content pages to a custom front end and leave checkout with the platform. That way you measure the effect on load time and conversion before rebuilding the whole store.

Agree up front how you will judge the trial. A mobile load time, a percentage of visitors who click through, or the number of hours marketing spends on a change. Without that agreement, the outcome becomes a matter of taste.

Make sure the data flows to your accounts stay untouched; what they look like is set out in connecting Shopify to your stock and accounting. Indicative prices for an online store are on what an online store costs.