Composable commerce: Smart move or high-risk investment?

Composable commerce has quickly become one of the most discussed models in digital commerce. According to the Composable Commerce Trends 2025 report, 80% of enterprise companies have already adopted or plan to adopt a composable architecture. It offers the appealing idea of assembling your technology stack from high-performing components so you can shape customer experiences, streamline operations and adapt as your business grows.

However, the same flexibility that makes composable commerce attractive also adds technical complexity that many merchants do not fully anticipate.

This article breaks down what composable commerce really is, why it gets so much attention, its hidden downsides, and when it’s the right fit. It also introduces a more practical way for merchants to achieve the same potential benefits while eliminating the challenges of operating on a composable architecture.

Composable commerce is a way of building your store using best-in-class components for each part of your store. These components operate independently and can be connected through APIs to work together as a complete system. 

Below is a detailed breakdown of how these components operate behind the scenes. This helps clarify both the potential of the composable model and the technical complexities that naturally come with it, which we will explore in the next sections.

You can choose a performance-validated component for each part of your store 

In a composable commerce setup, every area of your store can be powered by a different component. Instead of relying on one platform to handle search, content, pricing or checkout, you select the best pre-built component for each function.

These components may be offered by large eCommerce platforms such as Shopify, Commercetools, or by specialised vendors like Algolia, Contentful or Akeneo. As they are already used at scale in real stores, their speed, reliability, scalability and impact on conversion have already been demonstrated in practice. A clear example is Shopify’s Checkout component. It processes billions of dollars in orders annually and has been shown to convert up to 72% better than a typical checkout.

Each component operates independently 

A core principle of composable commerce is that every component has its own logic, data model and performance characteristics.

• Independent data and logic: Each component includes the backend logic and the data it needs to perform its specific job, all provided and maintained by the vendor.  For example, a pricing engine stores its own promotion rules and calculates pricing independently of your CMS, PIM or inventory system. Because these layers are fully separate, you can swap or upgrade the pricing engine without affecting the other components.

• Independent infrastructure and scaling: Each component runs on the vendor’s own infrastructure. It updates, scales and performs according to the provider’s service architecture. If one component slows down or becomes temporarily unavailable, it does not affect other components. 

You can connect these components using their APIs

Each component provides its own APIs, maintained by the vendor, which let your store access its data and carry out the tasks it is responsible for. This is also what allows different components to connect and support the features your customers use.

Note: APIs do not make components connect automatically. An orchestration layer is still required to determine which APIs to call and how to merge the information before displaying it on the storefront.

What is monolithic commerce?

A monolithic commerce architecture relies on a single platform where the storefront, backend logic and all core features such as product management, pricing, checkout, CMS, promotions, APIs and admin tools are delivered as one tightly integrated system. Everything runs on a single codebase and a single data model, which means the platform manages most of the internal coordination for you.

What is headless commerce?

Headless commerce separates the frontend (what customers see) from the backend (the commerce engine). The backend is still provided by a single eCommerce platform that supports a headless architecture.

What are the key differences between these two models and composable commerce?

The fundamental difference is that composable commerce does not depend on a single platform to determine how your frontend and backend must work. 

In monolithic and headless approaches, the entire backend is still bound to one platform’s architecture, rules, and limits. Headless removes frontend restrictions, but it does not change the underlying backend limitations. 

Composable Commerce takes a completely different approach by assembling independent, performance-validated components from different platforms, so neither your frontend nor backend is constrained by a single platform’s architecture.

Many merchants are paying close attention to composable commerce because it promises a level of flexibility and control that monolithic or headless commerce cannot. Below are the key reasons this model is generating interest.

Composable commerce gives merchants the option to assemble their stack from best-in-class components. This creates much greater control over both the customer journey and the operational engine behind it.

• For customer experience: You can select best-in-breed components for every stage of the customer journey, from search and content to recommendations, cart and checkout. As a result, you can optimise every step of the journey to make it feel more relevant, intuitive and aligned with how your customers shop.
  For example, a retailer might use Algolia for search, Nosto for recommendations and Storyblok for content, creating a more personalised and engaging discovery experience that reflects the brand’s strengths.

• For the operational engine: You can also choose high-performing components that run the operational engine, governing how products, pricing, catalogues, and orders are managed.
  For example, a merchant with advanced operational needs might choose Talon.One for pricing and promotions, Fluent Commerce for order management and Avalara for tax automation.

Together, this approach gives businesses the potential to build a commerce stack that matches their unique way of selling and operating. Instead of adapting the business to fit a single platform’s structure, the technology can be shaped around the business, enabling stronger commercial performance, clearer competitive differentiation and better operational efficiency.

Composable commerce allows each component of the system to evolve independently. This gives merchants more control over how their stack grows and adapts as business priorities change.

• Add or replace capabilities gradually as your operations evolve: Composable commerce allows you to update your system in smaller, targeted steps. You can add new capabilities or replace a single component without disturbing the rest of the stack. This leads to faster adaptation with minimal operational impact and reduces the need for large, high-risk rebuilds.

• Scale specific parts of your store independently: When traffic surges or sales campaigns drive higher demand, you can allocate more resources to high-impact areas such as checkout or inventory management, without scaling the entire system. This targeted scalability maintains strong performance during peak periods while keeping infrastructure and hosting costs under control.

Together, these promises paint a compelling vision: that by assembling only the capabilities they need, businesses can scale faster, adapt more easily, and spend smarter. This idea of flexible, efficient growth has kept composable commerce at the heart of industry discussions.

However, turning this vision of freedom and adaptability into reality is more complex than expected. It demands substantial time, strong technical expertise and continuous investment to keep many independent components working reliably as one system. These requirements often become clear only once implementation is underway.

The next section explains the hidden downsides that sit behind this promise.

Composable commerce provides teams with more freedom, but because each component operates independently, it also introduces higher technical complexity. This complexity appears both during the initial build and in the ongoing maintenance after launch.

Initial build: Making components work together

In eCommerce stores, a feature like checkout depends on multiple backend processes working together to produce a complete result for the customer. Tax needs to be calculated, shipping options generated, payment methods validated, and fraud checks completed before the order can proceed. These steps only work when each process returns the right information, in the correct format and at the right time.

In a composable setup, each of these processes may be handled by a separate component, built and maintained by different vendors. This makes coordination far more complex than in monolithic or headless commerce, where all backend logic sits within a single platform and is designed to work together by default. In composable commerce, your team must make these independent components operate as one unified workflow.

Areas that introduce technical complexity in the initial build include: 

• Different data structures: For example, a pricing system might send a product price as “10.00,” while another component expects it in a different format, such as “10.00 USD.” Because the formats do not match, your team must align them before the price can be displayed correctly. Even a small mismatch can show up as wrong prices, missing product information or inaccurate stock on the site.

• Coordinating how components interact: APIs expose information, but they do not coordinate how components should work together. Your team must build an orchestration layer that knows which component to call first, triggers each API in the correct order, and then combines the returned data into a complete response for the storefront. Designing this coordination logic requires strong backend engineering capability.

• Performance dependencies across multiple services: A single feature may need responses from several components before it can load. If one component is slow, the whole feature slows down. This is complex because the team needs a deep understanding of how each component behaves under different levels of traffic, and they also need to tune how and when data is loaded across multiple independent services to prevent unnecessary delays.

• Error handling in a distributed system: When your site relies on several independent components, any one of them can return incomplete data, fail temporarily, or behave unexpectedly. Your team must build fallback logic that keeps the site functional, whether by using cached data, showing partial information, or omitting optional elements. This is technically complex because the system must anticipate many different failure scenarios across multiple services and define clear rules for how the site should behave in each case.

• Testing the whole journey once components are connected: Because each feature depends on multiple components working correctly together, testing becomes more extensive. Teams must validate each component, every interaction between them, and the full end-to-end workflow. Issues often appear only when all components are exercised together, making testing both slower and more complex.

Ongoing upgrades and maintenance: Managing changes across all components

A composable system continues to require technical attention after go-live because each component operates and evolves independently. This creates ongoing work to keep the ecosystem aligned and stable.

• Ongoing vendor updates: Component providers regularly release updates, modify APIs, adjust data structures, or change how their service behaves under certain conditions. These changes happen at different times because each vendor follows its own product roadmap and release cycle. As a result, updates are not coordinated across components, and the team needs to track changes from multiple platform vendors and adjust integrations or data mappings to keep features working correctly.

• System-wide impact from individual changes: When the vendor updates a component or changes how its API works, it can affect the orchestration layer, monitoring setup and the end-to-end workflows that rely on that component. This often requires updating the coordination logic, adjusting how the system handles errors or performance issues, and retesting the affected features.

To summarise, composable commerce demands strong technical expertise and disciplined governance. If the technical setup or partner execution is weak, the entire ecosystem becomes fragile. Checkout errors, slow performance, or broken data flows can quickly undermine revenue and erode customer trust.

Compared to an all-in-one platform, early progress in a composable build typically takes longer. This is because in a composable approach, customer-facing features only work once several independent components have been connected, aligned, and are producing consistent outputs. Until this foundation is in place, many parts of the site cannot be released.

As a result, the business must wait longer before it sees any meaningful return from the project. Launches are often phased, and early versions may only include essential features while the rest of the ecosystem is still being assembled. 

For organisations with time-sensitive priorities, these longer timelines can stretch resources, delay commercial benefits, and increase the risk of project fatigue.

The total cost of ownership (TCO) of a store following the composable setup typically includes:

• Licence or subscription fees for each component: Most platform vendors price their components based on usage or scale, such as API calls, data volume, order throughput, or content entries. For example, Algolia (search) commonly prices its component based on the number of search requests and the number of products indexed. For a mid-sized retailer with a moderate catalogue and traffic, this can translate into several hundred to a few thousand pounds per month.

• Development and integration work: Because a composable setup is technically complex, development and integration require more specialised engineering and therefore cost significantly more than a traditional build.

• Middleware or orchestration infrastructure: Additional hosting or cloud services are often required to run the integration layer that coordinates all components. These create a recurring operational cost.

• Ongoing updates and compatibility management: Each vendor releases updates for components in different schedules, so your team needs to review API changes, update integrations, and retest affected areas. This ongoing work translates directly into additional development hours and higher long-term maintenance costs.

Composable commerce introduces a high cost during both the initial build and throughout ongoing maintenance. Its total cost of ownership is significantly higher than other models for two main reasons. First, licence and usage fees come from several vendors rather than a single platform, which adds multiple recurring subscriptions that stack together over time.  Second, keeping multiple independent components working together seamlessly requires more development, integration, testing, and long-term engineering effort, leading to a higher development and maintenance cost.

Composable commerce is often positioned as a pathway to greater flexibility, yet the model works well only when its architectural demands align with an organisation’s technical capability and the specific problems it aims to solve. The real-world cases below, which include examples of both success and failure, highlight the practical prerequisites for adopting composable commerce.

A success story: Mars and M&M’S 

Mars uses composable commerce to power the highly personalised M&M’S experience, where customers can customise colours, messages and packaging.

Standard eCommerce platforms could not fully support this level of personalisation, and Mars was carrying growing technical debt from ageing in-house systems. As the team noted, the M&M’S tech stack had “cracks in the foundation” and was being replatformed every three to five years.

To address this, Mars adopted a composable approach. It kept the custom capabilities needed for the M&M’S personalisation experience, while using best-of-breed components for functions such as product information, pricing, content and order management. This improved stability, reduced the need for repeated replatforming and allowed the brand to add new features without rebuilding core systems.

It is worth noting that Mars already had, and continued to invest in, strong internal technical expertise to orchestrate multiple components, manage integrations and maintain a reliable end-to-end experience. Without this capability, the composable model would have been difficult to operate sustainably.

A cautionary example: Amazon Prime Video

When the required technical maturity is not in place, composable or distributed architectures can become inefficient and expensive.  A well-known example comes from Amazon Prime Video. In a 2023 engineering article, its Video Quality Analysis team revealed that a monitoring service initially built using a distributed, serverless architecture, combining AWS Step Functions, AWS Lambda, and Amazon S3, had become increasingly difficult and expensive to operate. To resolve these inefficiencies, the team re-architected the service into a more consolidated, monolithic application running on Amazon ECS and EC2. The result was dramatic: over 90% reduction in infrastructure costs and improved scalability.

Lessons learnt from these real-world case studies

Mars’s case illustrates that composable commerce creates real value when organisations have a clear understanding of which specialised capabilities they need, which vendors can provide them, and realistic expectations of what those components can deliver. Mars adopted composable only after examining where their legacy stack was falling short and selecting vendor components that could address those gaps reliably. Their success came from making precise component-level decisions, not from the composable model alone.

Both case studies highlight one consistent prerequisite for composable commerce. Organisations must have the technical capability to integrate, orchestrate and operate a distributed architecture. Mars succeeded because it already had, and continued to invest in, strong engineering maturity. The Amazon Prime Video example shows the opposite. When a team does not have the expertise to manage a highly distributed design, the complexity and operational cost can quickly outweigh the benefits.

Making the right decision

Deciding whether composable commerce is the right approach is challenging because it requires a deep understanding of the composable's implementation realities, not just how it works in theory and the potential benefits it brings. This is where On Tap’s eCommerce consultancy services help you determine the right path forward. With nearly 20 years of experience across all major eCommerce models, including composable architectures, we help you assess whether this approach aligns with your growth priorities, operational models and technical maturity and make the right decisions.

Composable commerce introduces valuable capabilities, but not every business can or should commit to the level of technical ownership it requires. Carbon, by On Tap, offers a more practical path forward, capturing the strengths of composable commerce while being far easier and more cost-effective to adopt and sustain.

Why Carbon is a practical alternative to composable commerce

• Pre-integrated components built from nearly 20 years of eCommerce experience: Carbon gives merchants the ability to shape their storefront by choosing from best-in-class components such as advanced search, an optimised checkout, and enhanced merchandising tools. These components draw on On Tap’s nearly 20 years of eCommerce experience, providing a conversion-focused foundation from day one. 

• Expanding library of modules and managed integrations to extend capabilities: Carbon continuously expands its library of modules and enhancements, powered by Aitoc and On Tap’s ongoing product development. You can adopt new features or upgrade existing ones as your requirements change, without managing multiple external components. This approach gives businesses a controlled, low-risk way to extend their capabilities as they evolve.
  Integration Flow, On Tap’s managed integration platform, complements this by giving you the flexibility to extend operations seamlessly. It provides reliable connections to any systems you need, including PIM, OMS, and pricing engines.

• Technical complexity removed: Composable commerce requires strong engineering capability in both the initial build and ongoing maintenance. With Carbon, this complexity is absorbed by On Tap. Our team handles installation, configuration, updates and ongoing compatibility work, allowing merchants to benefit from flexibility without managing a complex technical architecture themselves.

• Faster time to launch: Carbon is designed for rapid deployment. Many stores go live in weeks, significantly faster than a fully composable build and even faster than most monolithic projects.

• Performance managed as one optimised system: Composable architectures require performance tuning and scaling for each component individually. Carbon removes this overhead. The entire storefront is managed as a single, optimised system, supported by On Tap Cloud’s auto-scaling infrastructure and AuditIQ’s 24/7 monitoring and real-time alerts. This ensures stable performance and fast load times during traffic peaks, without the rising cost of separately scaling multiple components.

• Strong security by design: Carbon is delivered as a unified, managed storefront, which reduces the exposure created by multiple third-party services. Security updates, patching and monitoring are handled centrally by On Tap, ensuring a consistently protected environment without the overhead of managing component-level risks.

• Lower maintenance cost: Compared to composable commerce, Carbon offers a significantly cost-effective total cost of ownership in both the initial build and long-term operation.
  For the initial build, Carbon uses a fixed annual licence fee that is lower than the accumulated licensing costs of multiple platform vendors.
  For the long-term operation, the cost of running Carbon is significantly lower than managing separate components in a composable setup. In composable commerce, each vendor updates their component on its own schedule, creating continuous work and driving maintenance costs to update these components and keep them compatible. Carbon comes with free lifetime upgrades that are delivered regularly, keeping the store up to date without additional expense. 

Composable commerce offers meaningful potential: the freedom to design distinctive customer experiences, shape your operational engine around how your business works, extend capabilities as you grow and scale performance in targeted ways. However, it also introduces significant technical complexity, longer implementation timelines and ongoing management that can be difficult and costly for many merchants to sustain.

In this guide, we introduced Carbon as a practical alternative for merchants who want the potential of composable commerce without the resource burden it requires. Carbon combines best-practice components for differentiated customer experiences, managed integrations to shape operational engines, and performance assurance into a single, predictable solution that is easier to adopt and scale.

With nearly 20 years of experience and a track record of helping merchants tackle complex growth challenges, On Tap brings rich commercial insights with deep technical expertise that can shape and implement your next path forward, whether that involves composable commerce or another solution. Contact us to discuss your goals and explore the best path forward.