Headless Shopify – pros and cons: when a custom front end makes sense and when Liquid is enough

Episode recorded in Polish before its release on 4 July 2023, so Hydrogen, Oxygen, apps and checkout on a headless store are described as they stood then. As of October 2026: since Hydrogen 2026-10, Hydrogen is a library that works with any JavaScript framework, Oxygen comes at no extra charge on paid Shopify plans, checkout stays on Shopify on headless stores too (you extend it with Checkout Extensibility), and Shopify did not buy Sanity: it invested in the company and partnered with it in 2022. The OPTISOFA store we give as an example in the takeaways was headless in 2023; when a redesign was due, it went back to a custom Shopify theme (Liquid): we designed and built the new store in 2025, launched in 2026. The store kept its Mimeeq integration and moved its modular sofa configurator to The Planner Studio.

The client who wanted to go back from headless to Liquid

Maciek: Hi! This is Maciek Czerniak, and this is another episode of our show, Flying with Shopify. Today, together with my business partner Kamil, we'll look at headless, a trend in e-commerce that has been gaining attention and popularity over the last few years. We'll consider when this approach to building e-commerce is a good idea and when it isn't. Hi, Kamil.

Kamil: Hello, Maciek.

Maciek: I don't know if you ever look through our HubSpot and what clients write to us in their enquiries.

Kamil: I do sometimes.

Maciek: You do, right? Recently I came across an interesting enquiry that made us record today's episode. A client wrote to us who needed to move from headless to Liquid: they already have headless in place, but they need to go back. What happened there? They write that an agency persuaded them to build their e-commerce this way because it would be more compatible with their product configurator, their customer panel and their specific requirements. But over time after launch it turned out to create more problems than benefits, and they'd like to take a step back. I think that's a good reason to talk about when we should actually go headless. But to answer that question, let's maybe start with what headless e-commerce, or headless Shopify, actually is.

Kamil: Before we get to that, I'll just say that I'd love to know the details of how they chose this tool, how the research was done, and how the requirements were gathered, both for the technology and for the way the business actually works. Because those are the important factors that determine whether we go headless at all or stay with the native solution. The second thing is awareness at the moment you make such a decision. Any analysis and research will help us make that decision consciously. But probably the most important moral of this story is that headless, even though, as you said, it has been very popular lately, it's a hot topic and a lot of people talk and write about it, is, contrary to appearances, not a cure for every ailment. You have to be very aware of that and remember it when choosing headless as your solution.

What headless is, and MACH architecture

Maciek: Right, shall we start from the beginning?

Kamil: Yes, let's start from the beginning: what is headless anyway? Let's roll up our sleeves and get to work. Let's take the bull by the horns. To even start talking about headless, we need to take a step back and talk about MACH architecture, because it's something broader, more extensive. MACH is a name made of four letters: M, A, C, H. M stands for microservices, A for the API-first approach, C refers to services hosted in the cloud, and only H is our headless. So as we can see, it's part of a broader perspective. Let's quickly go back to each of these elements. Microservices. When thinking about microservices, we should consider each element of our ecosystem as a microservice, as part of a larger, complex system made up of many elements, where e-commerce is only one of them. Microservices in our ecosystem can be, for example, an ERP system or, as mentioned in previous episodes, a PIM, a CRM, or even a CMS for managing an extensive content module or a community portal. Literally anything. A warehouse system, some WMS. Really, anything we want can be such a microservice. A refers, as I said, to using APIs as the communication channel between microservices. C, as you can guess, means that as many services as possible, if not all of them, should be hosted in the cloud to ensure not only security but also…

Maciek: Easy access.

Kamil: Easy access, performance and scalability, for example with increased traffic. Headless, the last element of MACH architecture, is nothing more than splitting, in our case, the e-commerce into two parts. With a headless approach, we don't use the native template or a template we built ourselves that sits inside our Shopify store. Instead, we decide to separate the front end and put it somewhere else as a separate entity that we build ourselves, custom.

Maciek: The front end meaning the part of the site the user moves around in.

Kamil: Yes, exactly, the user interface. Normally this interface is served, or delivered, to our user from the inside, directly by Shopify. That's where the content is generated, rendered and delivered. With headless we don't use that; instead we use an element of MACH architecture, which is communication through APIs. We call our e-commerce engine to fetch some data and to send some data.

Performance and flexibility: the most common reasons to go headless

Maciek: What's the benefit of separating the front-end layer from the back end?

Kamil: There are a lot of benefits. One that comes up very often in conversations with our clients is better performance. We're talking about…

Maciek: I have the impression that's the thing most often associated with headless, and probably the main motivation for many businesses to do something headless: the site will simply be faster, and nothing else is needed.

Kamil: Yes, exactly. Sometimes this huge benefit overshadows everything, because the performance gain really is big. The time it takes to reload a page when moving from one tab to another is really very short, so we gain on user experience, which we talked about in the previous episode. The user experience of a headless site is really great.

Maciek: Okay, go on.

Kamil: So that the pluses don't hide the minuses from us: we'll get to the drawbacks, because, as we said, the solution has its downsides. The second most common reason to consider headless at all is flexibility. That really is a fact, and it's worth paying attention to. We mentioned that we can have several microservices, several elements of our ecosystem, and that we decide to build our user interface, the front end, ourselves. Let's say we have a store, and in a completely different tool, on a different CMS, we have a very extensive blog, literally a community portal. But let's stick with the blog. It may turn out that putting the blog on a subdomain doesn't meet our business or functional expectations. We want everything in one place: content mixed with products, or the other way round, a product page enriched with content about that product, for example all kinds of guides. If we sell specialist products, that's very desirable. One element on the main domain and the other on a subdomain won't let us do that. When we decide to build our own front end, we can take any elements, in any form, from the e-commerce and from our CMS at the same time, and arrange and display them for the user however we like. So the flexibility is really very high.

Maciek: Okay, but I understand we're talking about a situation where we need to pull data from several different sources. It seems to me that if we only need to display things from the store, so products, images, descriptions and everything Shopify stores, then there are basically no limits on building the front-end layer. At least I don't see any.

Kamil: Up to a point, yes. But if we need our intervention to go a step further, even within that one tool, for example our own, fully customized checkout, then we'll be encouraged to go in the direction of a headless solution.

Apps and integrations on a headless store

Maciek: Okay. And in the context of that flexibility: what about the various integrations we already have?

Kamil: That's a very interesting question. Scalability and flexibility are listed as obvious, even fundamental benefits of headless. But there's a small trap here. Shopify out of the box, in the native approach, gives us certain elements, data structures and components by itself. With the template approach, when we have a theme designed by us or bought from a theme store, these components, modules and features are available to us very easily. But if we step outside that area and go headless, we have to be aware that all kinds of apps, modules and add-ons we buy for our store unfortunately won't work. That's a direct result of the fact that, as we've said at least twice already, we use the API to communicate between our storefront and the back end of our store, the Shopify engine. And those apps aren't available from that level; they're not available in the API.

Maciek: So if we want to switch on Klaviyo, another marketing automation tool or any other app, we have a problem.

Kamil: We'll be able to do it, but not as quickly and smoothly.

Maciek: We have to write it from scratch.

Kamil: Yes, exactly. We have to do that integration ourselves.

Is headless "future-proof"?

Maciek: Okay. You often hear the argument that headless solutions are future-proof, resistant to whatever happens in the future.

Kamil: I don't fully agree with that. I know it's not a simple matter, and you can't put it in one sentence and say yes or no. The headless approach, or MACH architecture in general, is based on many elements. That modularization, splitting things into individual elements, means that if we want to update some area, we usually make improvements to one or two components. We can also think about the benefit of the vendors of individual tools and technologies developing them further, so we gain from that. So why don't I think it's so black and white? Because we see how fast and how broadly Shopify is developing its own engine. It's developing not just the core, it's adding a whole range of new features. Besides, it listens very carefully to its users. You have to admit they're really great at watching what the market needs, so they're also good at delivering those add-ons, improvements and new elements. So I'm fairly calm about what the future will look like and whether those needs will be met. It's not so black and white that headless is a guarantee and without it we'll have a problem.

Maciek: It's also worth mentioning that Shopify is very well prepared for the headless approach, because we have an API for everything and can communicate nicely with every area of e-commerce. Second, Shopify itself is investing heavily in this approach and developing its own solutions and services around headless. I mean Hydrogen, Oxygen, or the purchase of the Sanity CMS a while ago.

Kamil: Exactly, but that shows two things. First, that headless really is a hot topic. That comes directly from what the market needs. Businesses are getting more complex, there are more and more services. We need to connect and integrate very different elements, and the data displayed on the storefront can come from different places. And second, that they're really good observers and actively make sure their product stays up to date. Launching a headless approach within Shopify is just proof that the market needs this solution.

Maciek: I think it also comes a bit from the direct-to-customer strategy Shopify follows, in the sense of selling where the customer is. On the one hand, that's of course investing in selling through various social media channels, whether on YouTube, Pinterest, TikTok and so on. But on the other hand, the headless approach gives us the possibility, and I think this came up at the beginning, that the storefront doesn't have to be an online store. It can be other things.

Kamil: Exactly. The best example is a mobile app, and we mean a native mobile app, not a responsive website. As you said, the storefront is then simply a native app installed on our phones, and the e-commerce engine, the thing that runs the whole transaction in the background, can be Shopify.

Maciek: It can also be wearables, various smartwatches, kiosks, information kiosks or a voice assistant. I'm waiting to see how we'll be able to shop through ChatGPT or other AI tools.

Kamil: Exactly. You can add to that very long list, for example, platforms that let us shop through text messages. With an ordinary text message you can confirm an offer you received by text and order a product you buy often. You expect that a month after your last purchase your supplier will ask whether you'd like to buy that product again.

Freedom of technology versus API limits

Maciek: Okay. Another argument that often comes up in conversations about headless is the freedom to choose the technology. I have the impression it's mainly raised by developers: thanks to headless they can build the front end in whatever they want and don't necessarily have to learn Liquid, which happens to be relatively easy to learn. But that remark comes up often. What do you think?

Kamil: There's certainly some truth in it, but I think the key is the reason behind that opinion. Shopify, as a SaaS tool, has its own architecture, its own requirements, but also its own limits. Working in that relatively closed space can make some of our colleagues uncomfortable, and maybe that's why they prefer more open tools. But I'd like to point out that when we move to an open architecture, we can't benefit from what SaaS products give us. There are many examples, but one is access to certain objects. For example, displaying all products in Shopify with the native approach is an almost trivial operation, while with headless we have to watch the limit of operations the API can handle per unit of time. So it's not that black and white.

Maciek: I think Shopify is trying to solve the problems you mention by offering its own headless framework, Hydrogen, which, because this is changing, has more and more in common with Liquid's methods and has access to those objects.

Kamil: It will certainly be a solution that connects the two worlds. On the one hand, we'll have a solution branded by Shopify, so we can expect it to have more methods and ways of accessing data than the API has today, and on the other hand it will use the flexibility and freedom we get from other headless technologies.

Drawbacks of headless: time, cost, developers and hosting

Maciek: Okay, we've talked a bit about the benefits of headless, and I hope we've managed to show that what sometimes looks like an obvious benefit has another side and often isn't clear-cut. Now I'd like us to talk about the other side, the drawbacks of this solution. I think we can give away the ending: it's not black and white, and you just have to accept that everything depends on the context you're in.

Kamil: It's certainly as you say: there's no perfect tool, and we'll say it once again, headless isn't one. Because of its complexity alone, it needs more development time. As we said, some modules aren't available, we can't use the benefits of a SaaS product, and we have to do everything with our own hands. That's why building such a store takes longer than with the native approach. And if it's time, it's automatically cost: we can expect the investment to take more money. In addition, Shopify with the native approach is something that, as you said earlier, you can almost build yourself, with some knowledge of the tool and general technical knowledge. There are even stores built with the help of people from outside IT. With headless we'll definitely need developers. Developers with the right skill set and commercial experience, who can build such an extensive architecture and handle it. So we can expect the financial outlay, if only for their salaries or hiring, to be much higher than with the native approach. So there are at least a few strictly financial and business aspects to take into account.

Maciek: There's probably also the question of infrastructure. If you set up a headless storefront, for now you usually host it yourself, on your own hosting, so you have to worry about that hosting, its security, and whether it can handle higher traffic. Unless you choose the solution Shopify offers, which is Oxygen.

Kamil: Okay, but let's assume we don't choose it. And even if we do, we'll still carry additional costs, because that's another thing that will really show up in our budget. As you said, when we decide to go headless, we have to provide hosting. We'll have to worry about it, monitor it, make sure it works and that uptime is as high as possible. Providers of course take care of that, but I think the most important thing, and it has to be said clearly, is that the worry shifts more towards us. With the native approach, Shopify takes very good care of everything and we have fewer worries. We can then focus on what really matters for our business at that moment.

SEO on a headless store

Maciek: We talked about compatibility with Shopify apps, about the fact that we can't really use the benefits, let's call them that, that Shopify gives us in terms of time-to-market and rolling out various features. What about search engine optimization, SEO?

Kamil: Here, contrary to some opinions, I think that with a headless approach we have a much better chance of doing it the way our business requires and the way we want. Working with the native approach, we operate within a certain structure, a certain architecture. The markup that robots then analyse is limited to some extent. It has its own structure.

Maciek: The link structure. We can't change it.

Kamil: Yes, exactly. Moving from the markup to the link structure, which is also quite important for SEO, we'll run into at least a few limitations. With headless we have complete freedom and can decide for ourselves which solution is best for us. So contrary to some opinions, I believe SEO can be done much better with a headless approach.

The advantages of a Shopify theme built in Liquid

Maciek: Right, let's also compare headless with the traditional approach, a Shopify theme built with the Liquid language. What benefits does that solution offer? I assume it will partly be the reverse of what we said about headless, but maybe there's something more.

Kamil: Exactly, so as not to demonize this solution and treat it like the devil's spawn. It's worth listing a few of the most important advantages. As I said, maybe not very clearly: with the native approach you can set up a store yourself. Launching the store, adding a few products, buying a theme that meets our financial expectations, our…

Maciek: Budget.

Kamil: Budget or visual expectations. Installing it on the store, adding a payment gateway we happen to have a contract with, and literally within one weekend you can start selling. We know such cases from our own history, so it's totally possible. We do it ourselves and very quickly. We have everything in one place and don't have to worry about obvious features like filtering or category pages. A whole lot of things come, as I said, out of the box. And, to be completely honest, relatively cheaply, because subscriptions even for the most basic Shopify plans are really low. A theme also costs a few hundred dollars at most, and it's a one-off expense. So on the budget side it looks really good.

Maciek: All right, let's move on. I think another benefit, sometimes a benefit and sometimes a problem, is that with the Liquid approach you can manage everything in one place.

Kamil: Yes, indeed. We manage both the product database and the content pages, if they're built on the Shopify engine, in one place. If we're at the start of our business journey as a young or beginner merchant, we probably won't have tools like a PIM, CRM or ERP. We won't be integrated with any warehouse or courier service, so our ecosystem is small. So I basically see no reason to complicate it artificially.

Maciek: Good. We can also mention that, in a sense, the Liquid approach makes us a bit less dependent on developers. We can do a lot ourselves.

Kamil: Yes. You certainly need less support from outside people. Developers may be needed when we want to go beyond what Shopify provides by itself. I think it's definitely worth having someone you trust to help you, if only with building the store, even with the native approach. But that person's involvement will certainly be much smaller than with so-called headless.

When headless makes sense, and when to stay with Liquid

Maciek: Okay, I think we can try to sum this up, close the loop and draw conclusions. Let's go back to the client from the beginning of the episode. What should guide them to make the right decision? Should they go headless, or at this stage of growth stay with Liquid after all?

Kamil: To answer that, I'd like to use my recent experience with a few of our clients and what we've already said about both solutions. To tie it together, I'd start with the key question I always ask a client: is their business already at the stage where it needs headless? What does their ecosystem look like? Which external tools do they use, and which…

Maciek: That's very important: which ones they'll use in the future. Analysing where we are today and where we'll be in a while, what our plans and business ambitions are, is really very important to consciously decide on maybe even implementing headless a bit earlier, so we don't have to do it twice. But if those prospects aren't entirely clear, if the client doesn't have a clearly defined plan or doesn't know today that they'll need some solution, they can use the native approach, for example to get to market faster, validate the product and the business concept faster, and spend the money saved on the native approach on, say, marketing.

Kamil: In other words, on reaching our customers and securing more sales volume.

Maciek: So we can say in conclusion that headless Shopify isn't a solution for everyone. Nor is it only for the big players. It depends on the specific moment you're at as a company. I think the conclusion is this: sometimes headless will slow you down operationally as a business, sometimes it will speed you up, and you have to sense that line, the moment to make the switch.

Kamil: Yes, exactly. As you said, in some situations headless can be overkill for a business. We're a young, still-growing brand, we're practically just entering the market, and right away we condemn ourselves to appearing in public only several long months after deciding to build our e-commerce. When with the native approach we can do it in a few weeks, be on the market much sooner and compete for the customer. So, as we said, you have to answer the question of which of these two tools, and each has its pros and cons, is more suitable for me right now.

Maciek: I think headless is a solution for companies that are already doing quite well, generating around half a million dollars in revenue a month, with enough technical complexity, their own resources and business processes complex enough that it makes sense. If it's only about site speed, it's definitely overkill.

Kamil: Definitely. Of course it's not a rule, but it's certainly a tendency that headless works much better for clients who already have an established market position and more complex business processes, who really need to integrate many tools and want to take their business to the next level.

Maciek: Because we can see a number of huge companies, enterprises, on the market. There was Giant Tiger, which recently migrated to Shopify and did it with the Liquid approach, because they really have fairly simple logic. They have a product, they ship it from the warehouse, end of story, and they don't offer anything complicated.

Kamil: And it's very good that they did it that way. They don't force solutions that won't pay back the investment. That's a very conscious, even pragmatic approach. And I always encourage the clients I have the pleasure of working with to show exactly that pragmatism when making this decision.

Maciek: Good, Kamil, thank you very much for the conversation. I hope we've managed to bring the topic of headless e-commerce closer to our listeners and viewers.

Kamil: Thanks to you too. Thank you for your time.

Maciek: And thank you all for your time as well. Do listen to and watch our next episodes. The marketing department told me to invite you to follow this channel wherever it's available, which I hereby do. Thanks, and see you. Talk soon.