Most businesses don’t need composable commerce. Many need headless. Some need neither.

Over the past few years, ‘headless’ and ‘composable’ have gone from engineering jargon to boardroom buzzwords. Vendors promise flexibility, speed and future-proofing. What they rarely mention is the bill: more systems to integrate, more engineers to hire, and more places for things to break.

This guide explains the three main approaches to e-commerce architecture (monolithic, headless and composable), what each costs in practice, and where each one fits.

Headless with a well-structured backend is the right level of flexibility for most growing businesses. Full composable pays off only when a specific capability, such as loyalty, pricing or fulfilment, is a real competitive advantage.

If you are deciding whether to replatform, or whether your current platform is holding you back, this should help you decide with fewer vendor slides and more clarity.

Key takeaways

Choose what you actually need. Most businesses do not need complex setups. A simple store setup is usually enough.
Understand the price. Simple platforms are easy to start but hard to change. Advanced platforms offer total freedom, but they cost more money and take more work to maintain.
Find the real problem first. Do not change your entire system just to follow a trend. Fix the actual bottleneck, like a slow website or difficult marketing tools.
Take small steps. Never replace your whole system at once. Clean up your current platform first, and only change the parts that need to grow.

Core Concepts and Terminology

Monolithic commerce combines the storefront, product catalogue, cart, checkout, order processing and administration in one integrated application. Traditional Magento implementations, OpenCart and PrestaShop are typical examples. Everything is in one place, which keeps things simple.

Headless commerce separates the customer-facing frontend (the ‘head’) from the commerce backend. The backend still manages products, pricing, inventory, carts, checkout and orders, and the frontend talks to it through APIs. One backend can then power a web storefront, a mobile app, a B2B portal and an in-store display.

Three architectures · monolithic, headless, composable

Composable commerce goes further. Instead of one backend handling every capability, the business assembles specialised services: a commerce engine for products, carts and orders, a dedicated search engine, a loyalty platform, marketing automation, an ERP and payment services. These communicate through APIs and events, and each can be replaced independently.

Monolithic keeps everything in one application. Headless splits the frontend from the backend through an API. Composable splits the backend itself into services joined by APIs and events.

The key idea: these are patterns, not product categories

Before comparing them, one clarification clears up most of the confusion in this topic. Monolithic, headless and composable are architectural patterns, not mutually exclusive product categories.

A headless implementation can also be composable.
A monolithic application can contain modular internal components.
Composable commerce can use both custom-built services and third-party platforms.

The real distinction is how responsibilities are separated and how independently each capability can evolve. Headless solves the presentation-layer dependency. It does not automatically fix limitations in the backend’s core business logic. A custom React storefront on top of a rigid backend is still a rigid system.

Side-by-side comparison

Dimension	Monolithic	Headless	Composable
Frontend and backend	Usually coupled	Decoupled	Decoupled
Business capabilities	Primarily integrated	Backend often remains integrated	Independently composed
Frontend flexibility	Platform-dependent	High	High
Backend flexibility	Limited to the platform and plugins	Limited to the chosen backend	High, per capability
Build cost	Lowest	Higher	Highest and least predictable
Time to launch	Fastest	Moderate	Slowest
Team and skills	Small team or agency	Frontend engineers plus API ownership	Engineers plus an architecture owner
SEO and performance	Handled by the platform	Depends on rendering approach	Depends on rendering and integration design
Vendor lock-in	To one platform	To the backend, less to the frontend	Spread across many vendors
Operational overhead	Lower	Moderate	Higher
Best at	Standard retail	Custom experiences and multiple channels	Specialised, differentiating capabilities

What the evidence shows: two real cases

The same architecture can be a win for one business and a burden for another. Two publicly reported cases show both sides. Both come from vendor-published case studies, so treat the figures as company-reported, not independently audited.

Case 1: Devialet, where headless paid off. The premium audio brand wanted to meet Google’s Core Web Vitals and improve its search competitiveness. It moved from Magento 1 to a headless Magento 2 setup built with the vendor Front-Commerce. The reported results: a 100% increase in conversion rate, a 25% decrease in bounce rate, and a Lighthouse performance score rising from 70 to 95, within 16 weeks. The lesson: headless worked because the problem was clear (frontend speed and SEO) and the frontend was the bottleneck. Part of the gain also came from upgrading Magento itself, so the architecture alone doesn’t deserve all the credit. Source: Front-Commerce case study on casestudies.com.

Case 2: Ministry of Supply, where headless became a burden. The fashion brand moved off a high-maintenance headless architecture onto a streamlined Shopify setup. The reported results: more than $170K saved annually in development costs, 95% of site changes now handled by the internal team without a developer, and release cycles moving from quarterly to bi-weekly. The lesson: when marketing and merchandising teams depend on developers for every banner and promo change, the flexibility of headless can cost more than it returns. One caveat: the case study was published by Nostra, a site-speed vendor whose product was part of the fix, and its 8% conversion lift is credited to that product, not to the migration. Source: Nostra case study.

What the two cases show together: the right architecture depends on where your bottleneck actually is. Devialet had a frontend performance problem that headless solved. Ministry of Supply had a team-autonomy problem that headless made worse. Diagnose first, then choose.

Where the major platforms fit

These platforms are often listed together, but they are not the same kind of product. The biggest practical difference is who runs it: a vendor (SaaS) or your team (self-hosted). That affects cost, control and the talent you need.

If you don’t have a dedicated engineering team, the right-hand columns matter more than the left. Open-source frameworks give you control, but you pay for it in engineering time, hosting and maintenance. SaaS gives you speed, but you accept its boundaries.

What it really costs

Architecture decisions are usually made on features and justified on flexibility. They are lived with as a budget. Here is where the money goes in each model.

Monolithic or SaaS

Build: lowest. A theme, some configuration and a handful of extensions can get a standard store live quickly.
Run: predictable. Subscription or hosting fees, plus plugin licences.
Team: a developer or agency on call, plus someone to manage the catalogue and store.

Headless

Build: meaningfully higher. You build a storefront from scratch instead of configuring a theme, and you also need checkout, search, preview and content editing to work well.
Run: two things to host and monitor instead of one: the frontend and the backend.
Team: frontend engineers comfortable with a modern framework, plus someone who owns the API layer.

Composable

Build: highest and least predictable. Each component adds licences, integration work and testing.
Run: a set of vendor contracts and infrastructure costs, plus ongoing effort to keep integrations compatible as each vendor updates.
Team: engineers, plus someone with the authority and skill to own the overall architecture. Without that person, integration sprawl is almost guaranteed.

The cost people forget: A monolith is cheap to start and expensive to reshape. A composable setup is expensive to start and cheaper to reshape. Which is better depends on how often your business actually changes.

Where headless and composable projects go wrong

Most failed replatforming projects don’t fail because the technology is bad. They fail because nobody planned for what happens next.

Marketing loses control. On a traditional platform, a marketer can change a banner, build a landing page or preview a promotion without a developer. In a custom headless frontend, you have to rebuild these abilities deliberately. If they aren’t, every content change becomes a developer ticket.
The plugin ecosystem disappears. Many monolithic platforms have extensions for reviews, wishlists, SEO and loyalty. Go headless and those extensions often stop working with your new frontend, so you either rebuild them or find API-based replacements.
SEO and performance regress. A poorly built headless storefront, such as one that renders mostly on the client, can load slowly and be harder for search engines to index. This is fixable with server-side or static rendering, but only if someone treats it as a requirement from day one.
Integration sprawl. Every new service adds an API to version, an authentication scheme, a failure mode and a bill. Two years in, nobody can fully explain how an order flows through the system.
Data goes out of sync. When inventory, pricing and customer data live in different systems, they will occasionally disagree. If you have not decided which system is the source of truth for each data type, customers will see it before you do.
Over-engineering for a problem you don’t have. The most common failure is solving a hypothetical future scale or flexibility problem while the real bottleneck, such as slow merchandising or poor conversion, goes untouched.

Warning sign: if the project plan spends more time on architecture diagrams than on what customers will experience differently, pause and revisit.

A practical migration path

You rarely need to replace everything at once, and you usually shouldn’t. A phased approach lowers risk and lets you prove value before committing further.

Phase 0: Diagnose. Write down what is actually blocking you today: slow pages, an inflexible checkout, an inability to launch a mobile app, or integration pain. If you can’t name the problem, you can’t tell whether a new architecture solves it.

Phase 1: Clean up the monolith. Before decoupling anything, fix the basics. Remove unused plugins, document your integrations and identify which parts of the system change most often. Many ‘we need to replatform’ problems turn out to be maintenance problems.

Phase 2: Decouple the frontend. If the storefront is the bottleneck, introduce a headless frontend. Many teams do this incrementally, moving one section first (for example, product pages or a new landing experience) while the rest of the existing site keeps running. This is often called the strangler pattern: the new system gradually takes over from the old one.

Phase 3: Extract one capability. Pick the single capability that would create the most value as an independent service, such as search, loyalty or pricing. Replace or extend it, integrate it through APIs and measure the result.

Phase 4: Repeat only if it paid off. Each extraction should earn its place. If Phase 3 did not produce measurable gains, more decoupling probably won’t either.

Rules of thumb

Decouple what changes most often or differentiates you most, not what is easiest to separate.
Decide the source of truth for products, inventory, pricing and customers before you start.
Keep a rollback path for every phase.
Don’t migrate during your peak trading season.

Which architecture fits you?

Scenario A: A conventional retail business. A retailer sells consumer products through a single online store. Requirements include product management, payments, shipping, promotions and basic customer engagement. A monolithic or managed SaaS platform is likely adequate. A composable architecture would add engineering and operational overhead with little return.

Scenario B: A growing omnichannel business. A retailer is expanding into mobile apps, B2B portals and multiple customer-facing experiences, and wants independent frontend development while keeping a central commerce backend. Headless is the natural fit. It delivers frontend flexibility without redesigning the entire commerce architecture.

Scenario C: A business with specialised requirements. Complex pricing, loyalty, customer segmentation, ERP integration, multiple sales channels and specialised fulfilment workflows. Competitive advantage depends on capabilities that standard extensions can’t support. Composable, applied selectively, gives the freedom to choose specialised components and build custom modules where needed, provided the business is ready for the added engineering and operational load.

AI readiness

AI is changing what commerce systems are asked to do: conversational product discovery, personalised promotions, natural-language questions about sales data, and agents that carry out authorised workflows across business systems.

For any of this to work safely, your systems need to expose reliable, structured product and customer data, well-defined APIs, and permissioned operations that an AI tool can call without bypassing business rules. API-first and modular architectures make that easier, but composable is not a prerequisite.

AI can be added to a traditional platform too. What matters is the quality and accessibility of your data and operations, not the label on your architecture.

Final thoughts: match the architecture to the business

Flexibility has a price. Each step from monolithic to headless to composable gives you more control and also more systems, more integration work and more skills to hire for.

Stay monolithic or SaaS if you run one main storefront with fairly standard requirements. Speed and simplicity are worth more than flexibility you won’t use.
Go headless if the frontend is your bottleneck: you need a custom web experience, a mobile app or a B2B portal on top of one commerce backend.
Go composable, selectively if specific capabilities such as pricing, loyalty or fulfilment drive your competitive advantage and standard modules can’t support them. Decouple those first, not everything.

The most common mistake is adopting composable architecture because it sounds modern, then spending a year maintaining integrations instead of improving the customer experience.

Before you replatform, ask three questions: What specifically is blocking us today? Which single capability would create the most value if it were independent? Do we have the team to run what we are about to build?

The best commerce architecture is not the most flexible one. It is the one that gives you the flexibility you actually need, without the complexity you don’t.

Sajid Ahamed

Ahamed Sajid is a technology delivery leader focused on building scalable systems that bridge business strategy and execution. With experience across fintech, mobility, e-commerce and enterprise platforms, he specializes in designing structured approaches to complex problem-solving and product delivery. He is particularly interested in how well-defined systems, processes, and technology frameworks can drive sustainable growth and operational clarity. Through his work, Ahamed advocates for pragmatic innovation where ideas are shaped into reliable, high-impact solutions that deliver real-world value.