When Headless Makes Sense on Commercetools
Phil Preston 14 min read
A Practical Guide for Enterprise Retailers Considering Pure Composable Architecture
Commercetools is often positioned as the “final form” of modern commerce architecture: MACH-certified, API-first, cloud-native, and inherently headless. Unlike Shopify, Magento, or WooCommerce, Commercetools doesn’t become headless; it already is.
That raises an interesting question for retail and eCommerce teams evaluating their next major architecture shift:
“If Commercetools is built headless by design, what does ‘going headless’ even mean, and when does it make sense to choose it?”
This article breaks down Commercetools’ strengths, limitations, and the practical decision points that determine whether it’s the right fit for your brand. It’s written for CTOs, engineering directors, digital leaders, and enterprise retail teams navigating the complexity of composable commerce.
Commercetools Today: What It Actually Is (and Isn’t)
Most platforms in this series started life as monoliths and evolved toward headless. Commercetools was built as a microservices-based commerce engine from day one. There is no theme layer, no templating system, no traditional admin UI for the storefront. Everything happens via APIs.
This gives Commercetools four defining characteristics:
1. Pure API-first design
Every feature; carts, products, orders, promotions is an API. This gives engineering teams total control over frontend, backend, and orchestration, but requires strong architecture discipline.
2. Microservices + event-driven foundation
Each domain (orders, carts, payments, inventory) operates as a discrete service. This reduces coupling, improves stability, and supports complex enterprise flows.
3. Cloud-native infrastructure
Commercetools is built for scale, with managed cloud infrastructure handling peaks and distribution. There is no server maintenance and no traditional hosting.
4. Fully decoupled experience layer
You can build with React, Vue, Next.js, Nuxt, Flutter, a native mobile app, or multiple front ends simultaneously. Commercetools does not dictate your presentation layer.
These qualities make Commercetools one of the most flexible commerce engines available, but also one of the most demanding.
Where Commercetools Shines
Commercetools excels in environments where customisation, scale, and extensibility matter more than speed of setup.
Enterprise-grade systems integration
If your business relies on ERP-driven inventory, OMS routing, PIM governance, WMS workflows, or highly bespoke pricing models, Commercetools adapts without fighting the architecture.
Multi-region, multi-brand retail
Because frontend and data layers are separated, brands can power dozens of storefronts across different markets, all from a shared commerce engine.
Complex catalogues and operations
Commercetools handles large SKU counts, multiple warehouses, multi-currency setups, and advanced attribute models without performance degradation. (Note: This is based on Commercetools’ publicly documented benchmarks)
Omnichannel commerce
Mobile apps, kiosks, in-store experiences, and future channels are all equal citizens because every commerce interaction is API-driven.
High performance under load
Event-driven architecture and elastic cloud infrastructure allow Commercetools to withstand significant traffic spikes (as reported in Commercetools’ own case studies).
Where Commercetools Struggles
Commercetools offers immense power, but that power comes with cost and complexity.
1. It requires a strong engineering team
There is no theme layer to “install.” Commercetools is a framework, not a turnkey storefront.
You must build:
A frontend
CMS integration
Search integration
Checkout UX
PIM/OMS/ERP orchestration
Middleware setup
Deployment pipelines
Monitoring
Without a mature technical team, Commercetools can overwhelm organisations.
2. It’s not ideal for speed-to-market
Brands that need a storefront up quickly often struggle. Commercetools is an investment in long-term architecture, not a rapid-launch tool.
3. Cost scales with architecture maturity
Licensing costs increase with usage, but the biggest cost is often the engineering and orchestration work.
(Based on typical SI implementation patterns; actual costs vary and should be verified case-by-case.)
4. Requires disciplined governance
With great flexibility comes the risk of chaos. Without standards for services, naming conventions, events, and integrations, systems drift.
Why Teams Consider Commercetools as Their Headless Path
Brands usually consider Commercetools when they reach one or more of the following conditions:
1. Backend limits are restricting customer experience
When the legacy platform cannot support modern UX patterns or real-time personalisation without brittle customisations.
2. Multi-channel growth has outpaced the platform
If your business has storefronts, apps, kiosks, marketplaces, in-store screens, and multiple brands, composable commerce becomes a structural advantage.
3. ERP/OMS/PIM integration demands exceed monolithic capability
Legacy platforms struggle with orchestration-heavy environments. Commercetools thrives in them.
4. When planning a multi-year digital transformation
Commercetools aligns well with organisations adopting cloud, event-driven architecture, or MACH principles.
5. Require full control over the checkout experience
Rather than hacking a monolithic checkout, Commercetools allows checkout logic to be designed exactly as needed.
Headless Architecture on Commercetools
A typical Commercetools headless implementation includes:
1. Frontend Experience Layer
Next.js
React
Vue
Nuxt
React Native
Flutter
This layer handles all user interactions, routing, and rendering.
2. Content Layer (Headless CMS)
Common choices include:
Contentful
Sanity
Storyblok
Prismic
CMS and commerce are completely separate systems.
3. Search / Discovery Layer
Often Algolia, Typesense or Elasticsearch. Commercetools intentionally does not include search out of the box.
4. Middleware & Orchestration
Custom Node.js middleware
GraphQL gateway
Event processors
Integration layer with ERP / WMS / OMS
5. Commercetools Commerce Engine
Manages:
Products
Variants
Carts
Orders
Pricing
Promotions
Inventory
Customer accounts
6. Cloud Infrastructure & Deployment
Hosted via:
Vercel
Netlify
AWS
Azure
GCP
This architecture is intentionally modular. Components can be replaced as needed without disrupting the whole system.
Real-World Use Cases
These Commercetools case studies illustrate a consistent pattern across industries: brands that succeed with Commercetools tend to have complex, multi-region operations, strong engineering teams, and a clear roadmap for composable transformation.
Below are verified examples with deeper explanations of the problems they faced and the outcomes they reported.
Audi (Global Automotive)
Audi’s shift to Commercetools was part of a broad, multi-year retail and digital experience overhaul built on MACH principles (Microservices, API-first, Cloud-native, Headless).
Audi needed a modern architecture capable of supporting a unified digital experience across dozens of markets, dealer networks, and product categories ranging from accessories sales to vehicle pre-configuration flows. Their legacy stack lacked the flexibility to support these regional variations and emerging digital channels.
Commercetools’ API-first design allowed Audi to centralise core commerce logic while enabling each regional business unit to build its own frontend experiences. This aligned with their strategy of creating reusable services, shared internal APIs, and scalable touchpoints across mobile apps, in-dealer screens, and brand websites.
According to Commercetools case studies, Audi gained:
Faster deployment cycles across international markets
Consistent global branding powered by shared services
Reduced technical debt, as legacy monolith components were retired
Improved customer experience, especially for mobile and multi-device usage
Audi remains one of the most frequently cited examples of large-scale automotive adoption of composable commerce.
Bang & Olufsen (Premium Audio)
Bang & Olufsen (B&O), known for premium audio and luxury electronics, encountered major limits with their existing platform as they expanded globally.
B&O needed to unify multiple regional storefronts while maintaining high visual performance standards. Their legacy platform struggled with performance differences across markets, and their internal teams found it difficult to experiment or localise content quickly without developer involvement.
B&O’s brand experience is central to their luxury positioning. Commercetools allowed them to rebuild their frontend in a modern framework (React/Next), decouple content through a headless CMS, and create a globally consistent yet locally adaptable commerce stack.
Reported outcomes (from Commercetools case studies):
Improved global site speed due to modern frontend rendering and cloud delivery
Increased development velocity, enabling faster iteration
Seamless regional deployments, giving B&O the agility to operate in local markets without duplicating infrastructure
Better content workflows, as marketing gained more control through the headless CMS
Bang & Olufsen’s adoption indicates the platform’s ability to support visually rich brands needing both performance and aesthetic precision.
Moonpig (Online Greetings & Gifts)
Moonpig, a major greetings-card and personalised gifting company, experiences extreme seasonal traffic peaks (notably Valentine’s Day, Mother’s Day, Christmas).
Moonpig’s legacy monolith could not reliably handle peak traffic events. The company needed a backend capable of supporting massive load spikes while also enabling rapid experimentation in the frontend and personalisation flows.
Why Commercetools made sense:
Commercetools’ elastic cloud infrastructure aligns well with seasonal retail
The API-first model allowed Moonpig to rebuild the frontend without disrupting business
Event-driven workflows supported Moonpig’s complex customisation logic
According to Commercetools publications, Moonpig achieved:
Significant improvements in uptime during peak traffic
Stable performance even under extreme load
Faster deployment and feature release cycles
Reduced risk associated with personalisation and product-configuration logic
Moonpig’s engineering team has publicly discussed the value of decomposing their monolithic stack, Commercetools played a central role in this transition.
John Lewis (UK Retail)
John Lewis & Partners, one of the UK’s largest retailers, adopted Commercetools as part of its broader shift toward a fully composable architecture spanning eCommerce, loyalty, content, and in-store experience.
The retailer needed an architecture capable of supporting:
multi-brand operations (John Lewis + Waitrose)
multi-region deployments
complex product data models
integration across internal legacy systems (PIM, ERP, OMS, CRM)
a unified omnichannel customer journey
Their existing platform could not deliver the level of agility required across dozens of internal teams and digital initiatives.
John Lewis selected Commercetools for:
API-first interoperability
Ability to integrate deeply with enterprise systems
Support for multi-service orchestration
Scalability across high-traffic retail events
Reported outcomes (from press statements and case studies):
Greater organisational agility with clear separation between back-end and front-end teams
Faster go-to-market for new digital features
Reduced reliance on monolithic releases, lowering operational risk
Consistent shopper experience across web, app, and in-store digital devices
John Lewis’ use of Commercetools demonstrates the platform’s viability for large retailers with heavy systems integration requirements.
When Commercetools Does Not Make Sense
Despite its strengths, Commercetools is not suitable for every organisation. In fact, many teams exploring composable architecture overestimate their readiness for it. Commercetools delivers immense flexibility and control, but this freedom comes with significant responsibility. The platform succeeds when adopted intentionally, with the right team structure and long-term architectural vision. It fails when chosen reactively, as an escape hatch from the limitations of a legacy monolith.
One of the clearest situations where Commercetools does not make sense is for brands seeking rapid time-to-market. Commercetools does not offer templates, themes, or an all-in-one administrative experience. Every part of the customer journey, from product pages to checkout flows, must be designed and built. This makes Commercetools a poor choice for teams that need to launch quickly, test a concept, or rebuild under tight deadlines. In these cases, platforms with stronger out-of-the-box storefront capabilities will deliver far more value with far less friction.
Commercetools also becomes a poor fit for teams without dedicated engineering capability. The platform assumes that you either have, or are ready to acquire, a multi-disciplinary development team capable of working across frontend, backend, DevOps, integrations, and orchestration. Without that internal maturity, Commercetools can overwhelm teams almost immediately. The absence of a pre-built storefront means brands must build and maintain everything themselves. Teams that lack senior engineering depth often struggle to manage this complexity, leading to delays, instability, and rising long-term costs.
Retailers who want a simple, centralised admin interface will also find Commercetools challenging. Because it is designed as a commerce engine rather than a monolithic suite, tasks like merchandising, content updates, promotions, and product structuring are distributed across multiple systems, typically a headless CMS, PIM, search provider, and custom admin tools. For organisations accustomed to a single backend where “everything lives,” this decentralisation can feel disjointed. It requires a mindset shift and strong internal coordination across digital, marketing, and operations teams.
Similarly, Commercetools is rarely the right choice for businesses with low complexity or modest requirements. Many retailers simply do not need the level of architectural flexibility it provides. If the business model is straightforward, single-region, small-to-medium catalogue, limited integrations, and predictable operational flows, the value of Commercetools does not offset the significantly higher engineering cost. Simpler platforms can meet these needs far more efficiently.
Commercetools also does not align with organisations seeking “Shopify-like simplicity.” Shopify, BigCommerce, and other SaaS platforms intentionally abstract away infrastructure, orchestration, and system design. Commercetools does the opposite: it gives you all the flexibility, but none of the shortcuts. Teams expecting a hosted, unified admin experience or a guided workflow system will be surprised by just how much architectural responsibility shifts back onto their organisation.
Finally, Commercetools often fails within organisations that lack strong architectural governance. Composable commerce requires discipline: naming conventions, service boundaries, API versioning standards, documentation, and clear ownership across teams. Without governance, Commercetools can lead to fragmentation, inconsistent service design, duplicated logic, and rising technical debt. This is why companies without an architectural framework, or the willingness to establish one, are rarely successful with Commercetools.
In short, Commercetools excels when used with intent, maturity, and a clearly defined roadmap. When adopted as a shortcut or a reaction to monolithic pain, it often introduces more complexity than it resolves.
Commercetools vs Other Headless Approaches
Commercetools vs Shopify Hydrogen
Shopify is simpler and cheaper initially.
Commercetools is more flexible for enterprise-level integrations.
Shopify fits DTC; Commercetools fits complex retail.
Commercetools vs BigCommerce
BigCommerce offers a faster start.
Commercetools offers deeper customisation at scale.
Commercetools vs Adobe Commerce
Adobe is stronger out of the box for merchandising.
Commercetools is superior in future-proofing and composability.
Commercetools vs WooCommerce Headless
WooCommerce is economical and fast to build with.
Commercetools is far more stable and scalable for enterprise needs.
The Fontis Perspective
At Fontis, we view Commercetools as one of the most capable and most misunderstood platforms in the headless commerce ecosystem.
It is powerful, elegant, and genuinely future-proof, but only when used in the right context.
“Commercetools is not a platform you adopt. It’s a platform you architect with.”
For brands undergoing multi-year transformation or investing in composable foundations, Commercetools provides the cleanest, most flexible backbone available. But for teams without engineering depth, Commercetools can create more complexity than it resolves.
Our role is to help organisations understand the trade-offs clearly and design a roadmap that aligns with their technical, operational, and commercial maturity.
When to Contact Fontis
If you are exploring Commercetools or evaluating whether a composable architecture fits your roadmap, Fontis can help with:
Solution architecture & evaluation
Composable commerce roadmapping
CMS and frontend strategy
Search & discovery integration
Checkout and cart architecture
ERP / OMS / PIM orchestration
Migration planning and risk modelling
👉 Learn more about headless commerce: https://fontis.au/fontis-commerce-stack/headless-commerce/
👉 Explore composable commerce guidance: https://fontis.au/fontis-commerce-stack/composable-commerce/
Read the previous article in this series about When WooCommerce Headless Makes Sense.
FAQ: Headless Commerce on Commercetools
1. What does “headless” mean in the context of Commercetools?
Unlike monolithic platforms, Commercetools is inherently headless. All commerce functions, products, carts, orders, pricing, and promotions are API-driven. The presentation layer is built separately using frameworks like React, Next.js, Vue, or native mobile apps. You design the frontend; Commercetools powers the logic beneath it.
2. Is Commercetools only suitable for enterprise brands?
Mostly, yes. Commercetools is best suited to organisations with complex architectures, multi-region operations, or deep integration requirements. Smaller brands can use it, but the engineering overhead makes it impractical unless there is a strong technical team or SI partner involved.
3. How long does a Commercetools launch typically take?
Timelines vary widely depending on the number of integrations, the chosen frontend framework, and CMS strategy. Unlike Shopify or BigCommerce, Commercetools doesn’t offer templated storefronts, so expect multi-month implementation cycles rather than quick launches.
4. Do we need a headless CMS with Commercetools?
Yes, almost always. Commercetools handles commerce logic only. Brands must integrate a headless content management system (e.g., Contentful, Sanity, Storyblok) for content workflows, page building, and multi-region delivery. This separation is intentional and core to the composable approach.
5. How does Commercetools handle omnichannel experiences?
Extremely well. Because everything is API-first, the same commerce data can be used across web, mobile, apps, in-store kiosks, marketplaces, and future touchpoints. This unified model is one of Commercetools’ strongest advantages.
6. Is Commercetools more expensive than other platforms?
Usually, yes. Commercetools licensing scales with usage, and the engineering investment is higher compared to monolithic or SaaS platforms. However, for enterprise retailers with complex needs and teams undergoing digital transformation, Commercetools often delivers better long-term value and flexibility.
7. How does checkout work on Commercetools?
Checkout must be built or integrated on top of Commercetools APIs. This provides full control over the UX, but requires careful design and integration with a payment gateway, tax engine, shipping APIs, and fraud systems. Commercetools does not include hosted checkout pages.
8. Can Commercetools integrate with our existing ERP or PIM?
Yes. Commercetools’ API-first model makes it ideal for environments with ERP, PIM, OMS, and WMS dependencies. Most enterprises use middleware or an event-driven integration layer to cleanly orchestrate these systems.
9. Is Commercetools suitable for replatforming from WooCommerce, Shopify, or Magento?
It depends. If your current platform issues are rooted in frontend flexibility, content velocity, or multi-brand complexity, Commercetools may be a strong fit. If your architecture or team isn’t ready for a composable, microservices-driven model, a headless version of your existing platform may be a safer transitional step.
10. How can Fontis help with Commercetools projects?
Fontis supports Commercetools across architecture, implementation, integration, and long-term scalability. We guide retailers through the adoption of frontend and backend decoupling, composable systems, CMS selection, and orchestration patterns that make Commercetools succeed in enterprise environments.