Every few years a term shows up in the ecommerce world that becomes fashionable at conferences and in articles, and "headless" has been that term for a while now. It gets talked about as if it were the mandatory future of any serious online store, which raises a reasonable question for any small business owner: do I need this? The short answer, in the vast majority of cases, is no. The long answer deserves an explanation, because in the handful of cases where it does make sense, the difference is real.
What "headless" means in plain terms
A traditional online store (standard Shopify, WooCommerce with a normal theme) works as a closed package: the backend (where the catalogue, orders, inventory and payments live) and the frontend (what the customer sees, the page design) are joined together and managed as one system. It's like buying a factory-built car: the engine and body already come assembled, they work well together, and if you want to change something you have to work within the options the manufacturer allows.
Headless ecommerce (literally "without a head") splits those two parts. The backend still manages catalogue, orders and inventory, but it's no longer "married" to a specific frontend: it communicates via API with whatever interface you want to build, whether that's a custom-built website, a mobile app, an in-store screen, or even a voice assistant. It's like buying the engine separately and commissioning a different designer for the bodywork: much more freedom, but also much more integration work to make the two pieces fit together well.
The real advantages of headless
- Total design freedom. You're not limited by the templates or technical restrictions of a closed platform; the frontend is built from scratch exactly as wanted.
- Much higher load speed. By decoupling the frontend, you can optimise in ways a traditional platform doesn't allow, which in theory improves user experience and SEO.
- One catalogue, multiple "storefronts." The same backend can feed the website, a mobile app, an in-store screen and a catalogue shown on social media, all synced from a single place.
- Scalability for very high traffic. Brands with massive traffic spikes (huge sales events, viral launches) benefit from an architecture built to handle load without falling over.
The costs almost never mentioned in the same breath
Here's the part that enthusiastic articles about headless almost never cover in as much detail as the advantages. Setting up a headless store requires an in-house or continuously outsourced development team: there's no "theme" to install and customise with a few clicks, every screen, every flow, every design update requires actual coding work. Initial development cost is usually several times higher than a well-built traditional store, and maintenance (security patches, updates to the various pieces you now have to manage separately) never goes away, unlike a platform like Shopify that updates itself.
On top of that, features that come built in on a traditional platform (optimised checkout, tax management, payment gateway integration, marketing apps) have to be built or integrated one by one in a headless project, adding time and cost to every piece of the puzzle.
Who actually needs headless?
The profile that genuinely benefits from headless ecommerce almost always shares these traits: high revenue (several million euros a year, not a few thousand), an in-house technical team capable of maintaining the system over time (not dependent on an outside developer hired once and gone), a need to sell across multiple distinct channels with a highly customised experience on each one (website, app, connected physical store, own marketplace), and a design or performance need that the traditional platform has already proven it can't meet, not a suspicion that "it could probably be better."
If your store makes a few hundred thousand euros a year or less, you don't have an in-house technical team, and your current platform (Shopify, well-configured WooCommerce) isn't putting real limits on you that you can point to specifically, headless isn't an upgrade, it's an expense that will eat up budget that would have a much better return invested in advertising, content, or improving the catalogue.
A middle ground: "composable commerce"
Between the traditional closed platform and a fully custom headless build there's an increasingly viable middle ground for mid-sized businesses: platforms that offer open APIs and frontend flexibility without forcing you to build absolutely everything from scratch. Shopify, for instance, allows a degree of headless customisation (using its Storefront API) without fully giving up the built-in order management, payment and tax features. For many businesses that feel the standard template falls short but aren't ready for a full headless project, this middle path gives considerably more room without the full cost of custom development.
An illustrative case: the store that went headless too soon
It's a pattern that repeats itself: a brand with good growth decides to make the jump to headless, encouraged by what it reads on tech blogs, invests a considerable amount in development, and a year later discovers that the marketing team can't even change a banner without asking a developer for help, something they used to do alone in five minutes from the platform's own dashboard. The day-to-day speed of execution (the kind that actually drives sales: launching a promotion, changing a piece of text, testing a new product page layout) suffered far more than the technical performance improved. Headless isn't bad in itself, but it requires the business to be organisationally ready for that way of working, not just technically ready.
What happens to the marketing team in a headless project
One of the least planned-for aspects before jumping to headless is how it will change the marketing team's day-to-day work, since on a traditional platform they're used to having almost total autonomy over banners, copy, promotions and page layout. In a poorly planned headless project, that autonomy disappears: any visual change now depends on a developer, turning tasks that used to take minutes into tasks that take days and compete for priority against other technical projects. The headless projects that work best explicitly invest in building a decoupled content management panel (CMS) that hands part of that autonomy back to the marketing team, rather than assuming they'll "figure it out" by filing tickets to development for every change.
How to assess whether your current platform is genuinely limiting you
Before seriously considering the jump to headless, it's worth doing an honest exercise: make a concrete list of the times, over the last six months, the current platform has literally prevented doing something the business needed (not "would be nice to have," but a real blocker that cost sales or time). If that list is practically empty, the current platform probably isn't the bottleneck, and the problem (if there is one) lies elsewhere: content, advertising, price, or operational execution. Only once that list starts accumulating real, recurring technical blockers does it make sense to seriously evaluate a migration of this scale.
The opportunity cost of putting resources into headless instead of something else
Every euro and every hour of development spent on a headless project are resources not being spent on other growth levers: improving content, investing in advertising, optimising the current platform's checkout. Before committing a considerable budget to a headless project, it's worth honestly asking whether that same budget, invested in more modest but more direct improvements to the current platform, wouldn't generate a faster, safer return. Technical architecture is rarely, on its own, the reason a business isn't growing more; there are almost always cheaper, faster-return levers waiting before reaching that point.
Common mistakes when evaluating a headless project
The first common mistake is asking a single agency or developer for a quote and treating that figure as the sole reference for the project's real cost. The price range between different providers for the same headless scope can be enormous, and comparing just one quote doesn't tell you whether it's reasonable or well above or below the market norm; it's worth getting at least two or three detailed proposals before deciding, paying attention not just to the final price but to exactly what each one includes in terms of ongoing maintenance.
The second mistake is evaluating the project purely from a technical standpoint, without involving whoever will use the system day to day (marketing, customer service, the product team itself). A project that technically ticks every box but that nobody on the team can operate without constant outside help ends up creating more friction than it solves. The third mistake is not explicitly asking about the contingency plan if the developer or agency that built the system stops being available: on a traditional platform, switching maintenance agencies is relatively simple because the system follows known standards; on a custom headless project, depending on whoever originally built it is a real risk worth having settled by contract before signing, not after the problem shows up.
The fourth mistake, perhaps the most common among ambitious small businesses, is getting swept up in the perceived prestige of the word "headless" instead of starting from a concrete business problem to solve. Asking first "what can't I do today that I need to do?" and only then evaluating whether headless is the right answer avoids committing a considerable budget to an architecture that sounds modern but solves no real limitation of the current business.
A fifth, more subtle mistake is not calculating total cost of ownership over several years, looking only at the initial development outlay. A headless project that looks affordable at launch budget can turn out much more expensive over a three- or four-year horizon once ongoing maintenance, security updates and the opportunity cost of a team spending time managing infrastructure instead of selling are added up. Always asking for a multi-year cost projection, not just the launch figure, gives a much more honest picture of whether the project genuinely pays off.
Frequently asked questions
Does headless automatically mean my store will be faster?
Not automatically. Headless architecture allows for speed optimisation beyond what a traditional platform permits, but only if the team building it actually puts in that optimisation effort. A poorly executed headless project can end up just as slow, or slower, than a well-configured traditional store.
Can I move from Shopify or WooCommerce to headless later if I grow?
Yes, it's a common path: start with a traditional platform, and only make the jump to headless once the business's volume and complexity genuinely justify it, not before. Migrating later, with real data about what limitations you actually have, usually gives better results than jumping ahead without proven need.
Roughly how much does it cost to set up a headless store?
It varies enormously depending on scope, but a serious headless project rarely comes in under several tens of thousands of euros in initial development, not counting ongoing maintenance. Compared to a few thousand euros to properly set up a traditional store, the investment gap is substantial.
Do I need in-house developers or can I outsource everything?
It can be outsourced, but you need an ongoing, reliable relationship with whoever maintains it, not a one-off project that gets delivered and forgotten. The headless system requires constant tweaks and updates, and depending on someone who doesn't respond when something breaks is a serious risk for a business that lives off the store.
Does SEO improve with headless?
It can improve if implemented correctly, thanks to greater speed and technical control, but it's not automatic. A well-optimised traditional store (good speed, good structure, quality content) can easily outrank a poorly executed headless store in SEO.
Is it worth it for a store selling in several countries?
Selling in several countries doesn't by itself require headless; there are traditional platforms with good multi-currency and multi-language support. Headless starts to be justified when, on top of selling in several countries, you need very distinct, customised brand experiences in each market, something that goes beyond translating prices and languages.