Published: 2026-04-10

Is the headless dream turning into a nightmare? 

A clear-eyed look at e-commerce architecture

There is a clear backlash in the e-commerce world right now against the "headless hype" of recent years. Many businesses have realised that, in the pursuit of total technical freedom, they have built complex monsters that demand huge resources just to keep alive. Time for a sober look at what headless actually costs, and when it is worth it.

Summary:

Headless e-commerce has been presented as the universal solution for modern commerce, but the reality points to significant hidden costs. Owning your frontend code means taking full responsibility for operations, maintenance, security and continuous modernisation, often at a cost that exceeds the platform licence itself. A composable architecture with a ready-made frontend gives you the same flexibility through open APIs, without the complexity. For most retailers, the choice is not about technical possibility, but commercial viability.

Headless was presented as the answer to everything

A few years ago, headless was presented as the future of e-commerce, with promises of total freedom to build exactly the customer experience you wanted, unlimited flexibility and the ability to choose the best technology for every part of the stack. The promise was compelling, and many businesses jumped into headless projects with high expectations.

Today, the picture looks different. More and more businesses are discovering that they have built solutions that cost enormous sums just to keep alive. The problem is not the technology itself, but that headless has been presented as a universal solution when it is, in reality, an architectural choice with very specific pros and cons.

When owning code becomes a burden

In a headless solution, you own the code for your frontend. That means you, or your consultants, are responsible for hosting, caching, performance optimisation and bug fixes. In a SaaS platform, this is included in the licence and handled by teams working on these issues for thousands of retailers at the same time.

Technical debt is unavoidable. Code written today is old in two years and needs modernising to keep pace with the development of frameworks such as React, Vue and Next.js. With a custom-built frontend, you need to budget for continuous modernisation of your codebase, or accept that your "modern" solution quickly becomes legacy. In a SaaS platform, this happens behind the scenes without you having to pay extra for it.

Kristian Iveling explains: "Consultants rarely tell you in the proposal that technical debt grows exponentially. Frameworks evolve, security patches need to be applied, performance needs to be optimised. Two years from now, you’re sitting on a codebase that needs constant rewriting."

What does headless really cost?

The focus often lands on the launch project cost, but it is the long-term running costs that become the real burden. Every standard feature built from scratch costs SEK 1,500 per hour or more in consultancy fees. A simple basket dropdown or product filter that would take minutes to configure in a platform can cost tens of thousands of kronor to build as a custom feature.

That is money not being spent on what actually differentiates your e-commerce business or drives conversion. Instead, it funds basic functionality that is already a solved problem in modern e-commerce platforms.

Agency lock-in: the problem nobody talks about

The e-commerce industry often warns about vendor lock-in with SaaS platforms, but agency lock-in is rarely discussed, even though it is often the bigger problem.

Headless is not just a technology shift, it is a change in how the business operates. The need for internal technical expertise is often underestimated, leaving you heavily dependent on external agencies. If the agency that built your unique React frontend leaves or changes staff, you are left with a codebase that nobody in-house understands or dares to touch.

The difference between agency lock-in and vendor lock-in is crucial: with a SaaS platform, you can always migrate to another provider, while custom-built code depends on the specific people who wrote it to be maintained efficiently. This can be devastating for profitability when more and more budget goes into simply keeping the solution alive.

The marketing team’s lost agility

This is where the irony kicks in. Businesses often choose headless to gain more flexibility, and end up with less.

With a good Site Builder, the marketing team can build a new Black Friday landing page in half a day using drag and drop. In a custom headless solution, you often need a developer to code the page and deploy it. That creates bottlenecks that dramatically slow down time-to-market.

"We see companies choosing headless for flexibility, only to end up with less flexibility than they had before. The marketing team can’t move without IT, and IT can’t move without consultants. That’s the opposite of agile," says Kristian Iveling.

Instead of focusing on content, conversion and the customer journey, the focus shifts to technical discussions about API calls and caching strategies. Time and resources that could have been used to drive sales are spent managing technical complexity instead.

Security and stability require continuous effort

A SaaS platform serving thousands of retailers has a decisive advantage through collective intelligence. If one retailer finds a bug or security vulnerability, it is fixed for everyone immediately. Performance improvements are tested and rolled out across the whole platform. In a custom-built solution, only you are testing your code, and every issue has to be solved specifically for your implementation.

Building your own frontend that scales perfectly during traffic peaks is both technically challenging and commercially expensive. A SaaS provider has dedicated teams focused solely on making sure the site can handle peak traffic, based on experience from thousands of retailers and millions of visitors.

In a headless environment, you are also responsible for frontend security, including protection against XSS attacks and other vulnerabilities. In a SaaS platform, the provider takes that responsibility with teams working proactively on security.

The pace of innovation becomes your real loss

In the long run, pace of innovation may be the strongest argument of all, but it is rarely discussed in the early project stages. When the platform launches support for things like AI recommendations or native video, it often appears as a widget in your Site Builder that you can activate straight away. In a headless solution, you first have to wait for the API to be released, and then pay consultants to build the interface needed to use the feature.

Apps and plugins for reviews, loyalty programmes or search are usually built to plug directly into the platform’s own frontend. If you want them in a custom headless frontend, you often have to build the integration yourself, which takes both time and budget.

"Innovation isn’t about owning the code. It’s about being able to adopt new functionality quickly when it increases conversion. We see customers testing AI features the same day we release them, while headless customers are still waiting for implementation budget approval," says Kristian Iveling.

When is headless the right choice?

There are legitimate use cases for headless. If you have extremely unique requirements that call for a tailored experience no standard solution can handle, if you have an in-house development team that can own and maintain the solution long term, or if your integration needs are so specific that full control over every pixel is essential, then headless may be the right choice.

But for most retailers, it is worth asking: are our needs really so unique that we need to own and maintain our own frontend code?

The smart alternative: composable with a powerful frontend

There is another route that combines flexibility with stability. A modern SaaS platform with a composable architecture and a no-code Site Builder gives you the ability to integrate the best-of-breed solutions that create real business value, while avoiding the burden of owning and maintaining core e-commerce functionality.

You get flexibility where it matters through open APIs and the freedom to choose the best solution for each function. At the same time, you get stability from a ready-made, battle-tested frontend that is continuously updated and improved without extra cost or project work.

The marketing team gets real autonomy to create and publish content without waiting for developers. New features and improvements are rolled out automatically. Security and performance are handled by specialists.

Kristian Iveling explains: "It’s not about choosing between control and simplicity. It’s about being smart enough to spend your time and money where it actually drives sales, not on maintaining basic e-commerce functionality like checkout flows and product listings."

You can think of it like cars.

SaaS with a built-in Site Builder: You lease a premium car that gets automatic updates, includes servicing and is ready to drive fast from day one. You can’t swap out the engine yourself, but you don’t need to be a mechanic either.

Headless: You buy an engine and hire a team of mechanics to weld together the bodywork, interior and wheels themselves. You get exactly the steering wheel shape you want, but every time you want to change the tyres, you have to call the mechanics, and there is always a risk the roof leaks when it rains.

The question is: do you want to own a workshop, or run a successful e-commerce business where you can focus on sales?