Composable's second coming: AI changed the equation

AI-assisted development is changing the build vs. buy math for your own frontend.

A few years ago, composable commerce was one of the most visible architecture trends in the industry. The idea was appealing: you build your commerce stack from independent parts and pick the best-fit solution for each need. In practice, though, that flexibility came at a price. Even just moving to a headless model often meant building your own frontend, and a fully composable setup added more integrations on top, along with responsibility for continuously developing the overall solution.

As companies started scrutinising their investments more critically, the advantages of a simpler setup came back into focus in many projects.

Now, the calculation made a few years ago is worth doing again. One of its key variables has changed fast: AI is changing how quickly and efficiently you can build and develop your own software.

Why composable took a step back

Composable commerce promised flexibility, the ability to choose the best tool for each need and independence from a single platform vendor. In return, though, the business took on more responsibility for the overall architecture.

The frontend was one of the most visible added costs of this model. Instead of a ready-made storefront, you had to design, build and maintain your own experience layer and connect it to the commerce platform, the CMS, search, customer data and other services.

And it wasn't just the first project. A custom frontend required ongoing development. At worst, marketing had to wait for the development team to make changes that on a ready-made platform they could have done themselves in minutes.

So composable didn't fail as an idea. In many cases, the price paid for its flexibility was simply too high relative to the benefit gained.

What changed: AI-assisted development

At Solteq, we have built and run custom frontends in customers' production environments for nearly ten years. AI didn't invent this way of building commerce for us. It has changed the way it can be done.

In our own development model, we have seen AI-assisted work speed up the building of well-defined views, components and storefront implementations in particular. AI reduces the manual work between design and finished software. Work can flow more consistently from Figma design to a shared design system, a component library and on to implementation.

When the architecture, components, integration patterns and development practices are already under control, building a new view or feature no longer means the same amount of work as a few years ago. The same components can be reused across brands, markets and channels, and each new implementation doesn't have to start from scratch.

This doesn't mean AI removes the need for design, architecture, testing or quality assurance. Quite the opposite. The faster code can be produced, the more it matters that the development model around it is in good shape.

“A custom frontend was long the expensive price of composable's flexibility. AI can increasingly make it part of the competitive edge.”

COMPOSABLE COMMERCE

AI changed the equation: before vs. now

The storefront is a choice again, not a default

A ready-made storefront is still the most sensible choice in many situations. With AI-assisted development, though, building your own experience layer is worth seeing in a new light.

The build vs. buy calculation should also take into account what happens to the storefront years down the line. We have seen several cases where a choice that was well justified at the time has aged poorly as the surrounding technology has evolved. The framework version the storefront runs on has fallen behind, the platform vendor's product development has slowed, or the platform has moved entirely to a new storefront solution. The old storefront still works, but developing and modernising it becomes, in practice, the merchant's own responsibility.

In a situation like that, a ready-made solution can over time turn into a kind of custom software, but without the original freedom of a custom solution. Developing within an outdated framework, platform dependencies and the constraints of a ready-made solution can be harder than working with a modern frontend built for your own needs in the first place.

We have also modernised implementations like these with AI assistance. It's precisely in these cases that the difference from before starts to become concrete: frontend debt accumulated over the years can be paid down and the experience layer renewed more efficiently than before, rather than having to replace the whole commerce stack at the same time.

As custom frontends become faster to build and continuously develop, it's worth asking again what you actually want to pay a licence for and what is worth owning yourself.

A custom frontend gives you considerably more control over the customer experience, the design system and the rhythm of development. It also lets you use the same experience layer on top of several backend systems, brands and markets. In business terms, that can show up as faster rollout of new launches, more room to experiment and the ability to differentiate the customer experience where it matters most.

But build vs. buy isn't settled by development hours

AI can reduce the effort of building and continuously developing your own frontend, but it doesn't remove the other responsibilities of custom software.

A custom experience layer still comes with maintenance, testing, security, accessibility, dependency management, production monitoring and continuity of expertise. Producing code faster doesn't make any of these unnecessary.

So the build vs. buy decision shouldn't be made on the basis of how quickly a new page can be generated. The more relevant question is whether your own experience layer brings the business enough freedom and reusability relative to the additional responsibility that comes with owning it.

You don't have to jump into composable all at once

Composable is easily perceived as a large architecture project where the existing stack is torn down and a new one built in its place. It doesn't have to happen that way.

For many, the first step can be much simpler: decouple the customer experience from the current commerce platform and build a modern frontend on top of it. The commerce engine, CMS, search and other systems can stay in place for now.

This is essentially headless modernisation. After that, other capabilities can be decoupled and replaced only when there is a genuine business need to do so.

The search solution can be swapped if the current one is no longer enough. The CMS can be renewed if content production is holding things back. The commerce engine can be replaced later without having to rebuild the entire customer experience at the same time.

A large one-off investment can thus be broken into manageable steps. Each step is triggered by a need, not by an architecture diagram.

COMPOSABLE COMMERCE

One experience layer, many platforms

A custom experience layer also gives more freedom to use data

When the experience layer is in your own hands, that freedom extends to customer data, personalization and experimentation tools as well.

This isn't because ready-made platforms can't do personalization. Many do it extremely well. The difference is that the company itself can decide where the personalization logic lives, what data is used and how freely the underlying services can be swapped.

A CDP, an experimentation platform or a personalization engine can then be seen as a separate capability rather than a permanent feature of the storefront.

Agentic commerce demands more than a good user interface

Until now, the most important interface for an online store has been the storefront, which a human uses in a browser or app. In agentic commerce, that assumption starts to change.

An AI agent may not need a visual storefront at all. It needs to access the store's capabilities programmatically: products, prices, availability, search, the cart, delivery options and eventually, possibly, ordering and paying too.

This is where headless and composable thinking have an interesting advantage. When the store's core capabilities are already available through APIs, they can be used from more than just the storefront.

The same product information can serve the webshop and an AI assistant. The same availability service can serve both the customer and the agent. The same commerce logic can also be exposed to new protocols and channels in the future.

Agent readiness, then, doesn't come from owning the frontend. It comes from the fact that the frontend, too, wasn't built as the only consumer of the store's capabilities.

A modern frontend also affects discoverability

In my two previous posts (Why product data is becoming the competitive battleground in modern commerce and SEO alone no longer decides what AI recommends) I covered how AI finds and understands products. The technical implementation of the online store has a role to play here as well.

Server-side rendering, performance, a clear page structure and machine-accessible content help make products and content easily reachable for users, search engines and other machine consumers alike.

They don't determine AI visibility on their own. As I noted in the previous post, AI forms its picture from a much wider digital footprint. But the online store is one of the important sources within that footprint, so its technical foundation needs to be in good shape too. Product data, the digital footprint and the technical foundation are different sides of the same question: how easily your store can be found and understood by machines.

Composable's old benefits, with a new calculation

Composable commerce hasn't changed in its basic idea. Its promise is still the same: flexibility, the ability to choose the right tool for each need, omnichannel reach and less dependence on a single platform's solutions. In business terms, these mean faster adaptation to the market, the ability to serve dealer and B2B ecosystems, and room to experiment without every change becoming a project of its own.

What is changing is the cost and speed of achieving those benefits. When building your own software becomes more efficient, one of composable's old trade-offs shrinks. At the same time, the value of a custom experience layer can grow if the same foundation can be used across several brands, markets and channels, and later in new AI-driven use cases as well.

When this isn't the right path

A ready-made platform is still a very workable choice in many situations. If the business model is straightforward, there's no great need to differentiate the customer experience and the platform's built-in features cover the needs well, building a custom frontend can still be unnecessary complexity.

Modern SaaS platforms have also evolved quickly and closed the flexibility gap.

A custom frontend and a gradually more composable architecture start to get more interesting when there's genuine complexity in the business: several brands or markets, demanding B2B, different channels for manufacturers and dealers, complicated integrations, or a need to manage the customer experience and its development more freely than usual.

It's not worth heading in either direction for the sake of architectural fashion. A modern experience layer can also sit perfectly well on top of a strong ready-made platform. It may not be about changing the commerce platform at all.

What this means

Composable never really went away. The flexibility it brought simply cost more, in many cases, than the company was willing to pay for it. Now one of the key variables in that equation has changed.

AI-assisted development doesn't make custom software free, nor does it remove the integration and management responsibility of a composable architecture. It can, however, reduce the effort of building and continuously developing your own experience layer so much that the old build vs. buy decision is worth reassessing.

At Solteq, we have built and run custom frontends in customers' production for nearly ten years now. What has changed isn't our ability to build them. What has changed is how quickly they can now be built, developed and reused.

That's why we wouldn't start by replacing the whole commerce stack. We'd start by asking a simpler question:

“If you could now modernise the customer experience with significantly less effort than before, what would that make possible for your business?”

We'd be glad to help find the answer.

Want to see our AI-assisted development model in practice?

We'll show you a demo and look at your situation together.

Get in touch →