Composable, headless, monolithic — what actually differs

Defining the three models

The terms monolithic, headless, and composable describe the same thing at different levels of decomposition. Understanding where each one starts and stops matters before choosing.

Monolithic ecommerce

A monolithic platform ships the storefront, the commerce engine, and the admin as a single system. Shopify, Adobe Commerce (Magento), BigCommerce with Stencil, and WooCommerce are all monolithic in their default form. The frontend and backend share the same codebase and the same deployment. To update the checkout, you deploy the same application that renders the homepage.

Monolithic does not mean inflexible. Shopify's app ecosystem is enormous. Adobe Commerce's extension framework covers most B2B requirements. The constraint is that customization lives within whatever the platform's architecture allows. Deep UX customization, unusual checkout flows, and independent frontend deployments are difficult or impossible without moving to headless.

Headless ecommerce

Headless separates the storefront from the commerce engine. The frontend — built in Vue, Nuxt, React, Next.js, or another framework — is a standalone application that talks to the commerce backend through APIs. The commerce backend does not render any HTML. It answers API calls.

This is the architecture behind headless commerce. The frontend and backend deploy independently. The team can redesign the storefront without touching the commerce engine. The commerce engine can be replaced without rebuilding the storefront, provided the API layer is abstracted correctly.

Headless does not prescribe what the commerce backend or the CMS is. It just means the frontend is decoupled. A headless stack with Norce as the backend, Storyblok as the CMS, and Klarna for payment is headless. So is a Next.js storefront on Shopify via the Storefront API.

Composable ecommerce

Composable takes headless further. Rather than having one commerce platform that handles products, search, checkout, and CRM, a composable stack assembles each capability from the best available specialist service. Algolia for search. Contentful or Storyblok for content. Stripe or Klarna for payment. Akeneo for PIM. Salesforce or Voyado for CRM. Each service is best-of-breed. Each connects via APIs.

Composable is not a technology — it is an architectural philosophy. The MACH Alliance (Microservices, API-first, Cloud-native, Headless) formalized it as a set of principles in 2020. commercetools, Contentful, and Amplience were founding members. The practical implication is a stack with more moving parts, more vendor contracts, and more integration work than a headless stack built around a single commerce platform.

Most projects described as composable are actually headless with two or three composable-pattern additions. True full-composable — every layer independently swappable — is rare outside large enterprise deployments.

How the three models compare in delivery

Time to market

Monolithic wins on time to market for standard requirements. A Shopify store with a quality theme can launch in weeks. A headless storefront built from scratch takes 4 to 9 months. A composable stack with multiple new vendors takes longer still.

The exception is frontend-as-a-service. A FaaS product like Frntkey ships a production-ready headless storefront with pre-built integrations. Most FaaS projects launch in 6 to 12 weeks — faster than most monolithic custom implementations, and far faster than a fully custom headless build.

Team requirements

Monolithic platforms are accessible to smaller teams and less technical merchants. Most configuration happens in an admin UI. Theme customization requires a frontend developer but not a specialist.

Headless requires frontend engineers with framework experience and a delivery partner or in-house team that understands API integration, BFF design, and deployment infrastructure. The team is larger and more expensive than a monolithic implementation.

Composable adds vendor management overhead on top of headless. Each service has its own API, its own contract, its own support channel, and its own failure mode. The integration work between services compounds. Teams that run composable stacks are typically large, technically mature, and have dedicated platform engineering capacity.

Flexibility and customization ceiling

Monolithic is the most constrained. Custom checkout flows, unusual product configurators, B2B-specific pricing logic, and multi-brand storefronts all bump against what the platform allows. Extensions help but do not remove the fundamental constraint.

Headless raises the ceiling significantly. The storefront is a first-class software application. Any UX pattern that can be implemented in a modern frontend framework is achievable. The commerce backend still has its own constraints, but the storefront does not inherit them.

Composable adds flexibility at the backend layer too. Swapping the search engine, replacing the CRM, or adding a dedicated PIM does not require rebuilding the storefront. For organizations that need to move fast at the platform layer — mergers, replatforming mid-lifecycle, adding new markets — composable architecture makes those changes tractable.

Total cost of ownership

Monolithic has the lowest upfront cost but can become expensive as customization accumulates. Platform fees, app subscriptions, and the cost of working within constraints add up over time.

Headless has higher upfront build cost but lower long-term constraint cost. A well-built headless storefront is easier and cheaper to change than an over-customized monolithic one. The break-even point depends on how much the storefront needs to change after launch.

Composable has the highest integration cost and the highest ongoing vendor management cost. It is justified when the business genuinely needs best-of-breed at every layer — typically for large catalogs, complex B2B pricing, multi-market operations, or storefronts where search quality is a primary commercial differentiator.

Decision framework: which model fits which project

Choose monolithic when: the catalog is standard, the team is small, the storefront requirements are not unusual, and speed to market dominates. A well-run Shopify or BigCommerce store will outperform a badly-built headless one.

Choose headless when: the storefront experience is a real competitive differentiator, the team can sustain the delivery complexity, the project runs on Norce or Shopware where headless is the natural model, or the merchant sells across multiple channels from one catalog.

Choose composable incrementally: start headless, add composable layers when specific gaps justify the overhead. Better search is usually the first composable addition. Dedicated PIM is common second. Full-composable from day one is rarely the right starting point.

Frntkey delivers into the headless model with composable-ready architecture. The storefront connects to Norce or Shopware as the commerce backend. Storyblok ships bundled as the CMS. Search, CRM, reviews, and payment vendors plug in via pre-built integrations. The architecture is composable-ready without requiring the full composable overhead on day one. See how it compares to alternatives on the compare page.