We are deciding which approach fits.
Monolith, headless or composable: the answer depends on what you are trying to do, not on the technology.
Composable Commerce – Architecture That Follows Your Processes
We build modular commerce platforms on commercetools – anchored in your business processes, connected to your data and AI, designed ahead for your growth. B2C, B2B and D2C for retail and manufacturing across the DACH region. From target architecture to running operations.
Where Are You Right Now?
We are planning the build.
You want to know how a project like this is scoped and when things are actually done.
We have a platform that is not holding up.
The stack is modular, but releases drag, integrations are brittle, costs are drifting.
What Composable Commerce Means
Composable Commerce is an architectural approach in which the commerce engine, content management, search, payment processing and other capabilities run as independent services connected through APIs. Each component is selected, deployed and replaced on its own. The counter-model is the monolith, where every change requires deploying the entire system.
The value does not lie in modularity itself. It lies in the fact that a change in one place does not touch everything else: releases get smaller and more frequent, the second market costs less than the first, and a new channel arrives without a system rebuild.
The MACH Alliance no longer explains the approach through its four letters, but through three properties: Open. Composable. Connected. Away from the technology checklist, towards the question of whether an architecture stays connectable.
That question matters most with AI. In the MACH Alliance Enterprise Technology Report 2026, a survey of 600 technology decision-makers across seven markets, 78 percent of organisations with fully rolled-out composable architecture report measurable ROI on their AI investments – against 13 percent of those still in the planning stage. AI initiatives rarely fail on the model. They fail because the data is not reachable.
- Components replaceable one by oneCommerce engine, CMS, search and payment run as independent services connected through APIs
- Releases without a rebuildA change in one place does not touch everything else – smaller releases, shipped more often
- The second market costs lessCountries, brands and tenants get configured, not copied
- Ready for new channelsNew touchpoints and AI agents connect to existing APIs without rebuilding the platform
What Composable Makes Possible
The three approaches do not differ in technical elegance. They differ in what they allow you to do day to day.
| What you want to do | Monolith | Headless | Composable on commercetools |
|---|---|---|---|
| Roll out a new market or brand | New project | New frontend, backend limits remain | Configuration instead of a copy |
| Change campaigns and content | On the release date | On the release date | Any time, without a deployment |
| Choose search, loyalty or payment freely | Whatever ships with it | Whatever ships with it | Free choice per component |
| Use prices and terms from your ERP | Rebuild and keep in sync | Rebuild and keep in sync | Connect – the ERP stays the source of truth |
| Add a second frontend, such as a partner portal | Separate application alongside | Separate application alongside | Additional storefront on the same backend |
| Take AI use cases into production | Data paths are missing | Partly open | Data available through APIs |
| Replace one component in five years | New project | Backend project | Swap the component |
The difference rarely shows on launch day. It shows at the second market, the third channel, and the first requirement nobody knew about when the platform was built.
What Composable Is the Right Answer For
Composable plays to its strengths where complexity is real and cannot be simplified away. If three or more of the following apply, the approach pays off.
- Several markets, brands or tenantsToday or on the roadmap
- Pricing logic in the ERPPrices and terms live in the ERP and should stay there
- More than one frontendShop, partner portal, app, marketplace connection
- Business teams free of release datesContent and campaigns should run independently of deployment schedules
- Specialised requirementsFor search, loyalty or configuration, better systems exist than the platform module
- AI initiatives aimed at productionUse cases should reach production rather than stay in pilot
And Where Another Path Gets You There Faster
| Your situation | The faster path |
|---|---|
| One market, one assortment, stable requirements | An integrated system – more economical long term |
| A specific symptom, such as weak search | A targeted fix within the existing stack |
| Legacy system running out of maintenance, but the architecture still holds | Replatforming without changing the architecture |
| Product data not yet reliable | Data foundation first, platform second |
Which row your project falls into is a conversation, not a proposal.
How foobar Agency Builds Composable Commerce
We build Composable Commerce on commercetools. Partner since 2019 – and every composable commerce project we have started in recent years runs on this platform.
The surrounding stack comes from a settled repertoire: Hygraph, Storyblok or Contentful for content, Algolia or FactFinder for search, Next.js for the storefront, Vercel and Fastly for delivery. It runs on the cloud you bring – AWS, Google Cloud or Azure. We adapt to your cloud strategy, not the other way round.
Capability mapping before system selection
Before any system decision, we map every requirement to the layer where it gets solved. Four categories:
| Classification | Meaning |
|---|---|
| Standard | Covered by the platform |
| Configuration | Achievable with platform means |
| Extension | Custom development, effort estimated |
| Different layer | Solved in the ERP, PIM or a line-of-business system – no gap in the overall solution |
The result is a matrix across all requirements. It shows where effort arises and where it does not, and which requirements actually drive system selection. Scope, estimates and architecture decisions build on it – traceable, row by row.
Our approach
Five Principles in Delivery
Right-sizing
The cut follows the requirement, not the catalogue. An enterprise OMS for modest fulfilment costs money in the same way a missing search engine does on a six-figure catalogue.
Re-use first
We do not build on a greenfield. Existing systems, services and patterns in your landscape get reused; we add deliberately.
Integrations first
ERP integrations decide the schedule. They sit at the start of delivery with us, validated by an integration spike that tests interfaces, data quality and update frequencies before the plan depends on them.
Configure, do not duplicate
Country, brand and tenant differences run through feature flags and central settings, not copied codebases.
Nothing thrown away
Data models and interfaces are cut so that later extensions do not require a rebuild. It costs hours in design and saves weeks in operation.
Four Phases to a Running Platform
Clearly bounded phases with defined outcomes. We offer the early phases at a fixed price.
Phase 1 · Architecture review
For organisations already running a composable or headless platform. Eight areas under review: system landscape and data flows, code and implementation quality, frontend and integration layer, backend and service landscape, content architecture including roles and permissions, infrastructure and operations, security and data protection, development processes.
We do not only read documentation and architectural decision records – we examine the architecture as actually implemented: codebase, configurations, pipelines, monitoring. Where diagrams are missing or out of date, we produce our own.
Phase 2 · Discovery
Ten facilitated workshops with defined outcomes: target picture and project mandate, stakeholders and personas, business processes and use cases, functional requirements, system landscape and integration map, non-functional requirements including performance, security and SLAs, UX exploration, prioritisation by business value and complexity with MVP definition, backlog for the first two sprints, sign-off.
Discovery ends with a go/no-go decision and a backlog you can build from the next day. We calculate from realistic scenarios rather than best cases, and state assumptions and exclusions openly.
Phase 3 · MVP to release candidate
Two-week sprints with cross-functional teams covering engineering, QA, UX and product ownership. Design sprints run ahead of development sprints. From two parallel streams onwards, a project leadership board coordinates cross-cutting risks and dependencies.
Testing happens early rather than at the end: testable acceptance criteria, automated tests on every commit and in every pipeline, regression tests on every release.
Development is AI-assisted. We automate repetitive implementation work – with defined quality gates and without your data leaving the project environment. This shortens implementation timelines considerably and shifts capacity to the parts of the platform that differentiate your business.
Phase 4 · Rollout and operations
A pilot market first, then rollout per country or tenant. Before every go-live: integrated system test with all connected third-party systems, load and penetration testing by independent parties, user acceptance testing, data migration with mapping and validation. Then hypercare and running operations.
From experience: a composable build from requirements gathering through design and architecture to ERP and PIM integration reaches production in six to nine months – at the lower end with a tightly cut scope and reliable interfaces. With several markets and tenants, the pilot market is the more meaningful milestone than the overall go-live.
- Phase 1 · 2 to 4 weeksArchitecture review: overall assessment, prioritised recommendations with effort and risk, preliminary roadmap
- Phase 2 · 3 to 5 weeksDiscovery: fixed-price proposal for the MVP scope, cost indication with ranges for expansion stages, backlog for two sprints
- Phase 3 · 3 to 4 monthsA reliable release candidate to build on – not a prototype
- Phase 4 · Rollout and operationsPilot market, then rollout per country or tenant, followed by hypercare and running operations
Three Ways to Cut the First Release
The most common mistake in composable projects is an MVP that is not one. There are three proven cuts – which one fits is decided in discovery.
Assortment cut
Start with part of the assortment. Complex products, variant logic and configurators stay out initially. Fits when a viable slice of the assortment can be isolated cleanly.
Functional cut
The happy path gets built; edge cases are deliberately excluded and documented. Fits when processes are broad but shallow.
Organisational cut
Go live for selected customer groups, locations or sales partners. Fits in B2B where permission and terms structures are complex and a subset can serve as the reference.
Components and Integration Patterns
commercetools as the commerce engine, headless CMS with Hygraph, Storyblok or Contentful, search and recommendations through Algolia or FactFinder, storefront on Next.js cut into microfrontends, backend-for-frontend between storefront and services, delivery through Vercel and Fastly, cloud infrastructure on AWS, Google Cloud or Azure, identity management as its own source of truth, an integration layer to ERP and PIM, and a data and analytics layer alongside commerce and content.
For the recurring part we use our own accelerator: a performant frontend, a ready backend-for-frontend layer and integrations into the commerce engine, search and CMS – including the integrations between those systems. That saves commodity effort and moves budget to where your business differs.
The ERP stays the source of truth
We connect it through a deliberately thin middleware layer rather than point to point. Article master data, prices, stock and customer data stay in the ERP; the middleware transforms and routes changes and passes orders and status updates back. This way the ERP needs to know nothing about storefront concerns, both systems remain independently replaceable, and there is exactly one place for monitoring, error handling and replays.
Prices and availability are two tasks, not one
On listing pages and in search, a dedicated price cache service delivers, loaded asynchronously and updated by event or batch. In cart and checkout, we simulate live against the ERP using external prices and external tax in the commerce engine. Part of that design is deciding what happens when the ERP is briefly unavailable.
Data from day one
Order, customer and interaction data flow into a central data platform – usually Snowflake with dbt modelling – which then serves reporting, predictions and AI use cases. Define the data paths after launch and you build them twice.
- Synchronous API callsWhere an immediate response is required: cart operations, credit checks at checkout, availability checks on click
- Asynchronous eventsWhere downstream systems react: a placed order triggers fulfilment, the ERP posting, loyalty credit and shipping communication
- Bulk importsFor large data volumes on a fixed rhythm: nightly article and price updates
Operations
What Holds After Launch
An automated path to production
Deployments fully automated, promotion to production a deliberate click, rollback automated as well. Manual operation is expensive; modular operation is not.
Observability
Uptime monitoring, error tracking, logs, alerts. Plus operational KPIs that actually get measured: availability, mean time to recovery, service level adherence, cycle time.
One place that steers
A best-of-breed stack needs defined responsibility across system boundaries: who detects an incident, who classifies it, who coordinates the vendors, who communicates to the business. We usually take that role on – together with architecture, delivery, project management, testing and operations.
Documented decisions
We work in your systems. Architectural decision records capture why something was built the way it was. The knowledge stays with you, including for whoever makes the next decision two years from now.
Composable architectures in retail and manufacturing
Frequently Asked Questions
Composable Commerce is an architectural approach in which the commerce engine, content management, search, payment processing and other capabilities run as independent services connected through APIs. Each component is selected, deployed and replaced on its own. The counter-model is the monolith, where every change requires deploying the entire system.
Headless separates the frontend from the backend – the backend stays monolithic. Composable also breaks the backend into replaceable services. Headless is a frontend decision; composable is an architecture decision. A headless setup on a monolith gives you a modern frontend, but no ability to replace individual capabilities.
No, the two terms describe different things. Unified Commerce is a goal: a consistent experience across all channels, with a shared view of customer, stock and order. Composable is the architecture that gets you there – and that keeps holding when channels, markets or requirements shift.
Organisations with several markets, brands or tenants; with pricing and terms logic in the ERP; with more than one frontend; or with AI initiatives that need to reach production. With one market, one assortment and stable requirements, an integrated system is more economical long term.
commercetools. We have been a partner since 2019, and every composable commerce project we have started in recent years runs on this platform. For projects with a clearly bounded scope and a short time to market we also implement Shopify Plus – though that is not a composable setup, it is a deliberately different decision.
The one you bring. We work on AWS, Google Cloud and Azure and follow your cloud strategy, your existing agreements and your compliance requirements. For storefront delivery and edge caching we use Vercel and Fastly.
A first reliable release candidate is realistic in three to four months. A full build including requirements gathering, design, architecture and ERP and PIM integration runs six to nine months. With several markets, currencies and tenants, correspondingly longer. Our AI-assisted development process shortens these timelines considerably: repetitive implementation work is automated, with defined quality gates and without client data leaving the project environment.
Total cost comprises licences for the commerce engine and surrounding systems, integration effort, frontend development, data migration and operations. The largest drivers are the state of your source systems and your data quality – which is why reliable figures only emerge after discovery, and why we offer discovery at a fixed price.
Through a deliberately thin middleware layer rather than point to point. The ERP stays the source of truth for article master data, prices, stock and customer data. The middleware transforms and routes changes and passes orders and status updates back. Both systems remain independently replaceable, and monitoring and error handling sit in one place.
Separated by use case. On listing pages and in search, through a dedicated price cache service updated by event or batch. In cart and checkout, through a live simulation against the ERP using external prices and tax. Part of that design is deciding what happens when the ERP is briefly unavailable.
Next step
Composable Commerce on commercetools.
Whether it is a new build, a replatforming or a review of your existing platform: we start by taking stock.
Get in touch
We look forward to your enquiry.
Please accept marketing cookies to load the registration form.