Before Going Composable: The Decisions Retailers Need to Make First

Quick Answer: A retailer should consider composable commerce when a specific business capability needs more flexibility than its current platform can reasonably provide. Before choosing technology, identify that constraint, assign ownership of the affected data and integrations, and define how the business will measure success. A limited change with clear acceptance criteria offers a stronger starting point than a commitment to replace the entire commerce stack.

An ecommerce platform can be frustrating without needing replacement. Slow campaign launches might come from approval processes. Inconsistent product information might originate in merchandising workflows. Checkout problems might involve a payment integration that would follow the business into its next architecture.

These distinctions matter because a platform migration can absorb considerable attention while leaving the original problem intact.

The useful starting point for composable commerce is a business decision: which capability needs to change independently, and what would that independence make possible?

For a retailer, the answer might be better product discovery, more flexible promotions, or a reliable pickup experience. Each leads to a different project. Treating them as one broad modernization program makes it harder to see which investment is actually working.

Start With the Constraint You Can Describe

For executives asking what is composable commerce, the basic definition is straightforward: it is an approach to assembling commerce capabilities from components that can be selected and integrated around business requirements. Search, content, checkout, and other functions do not necessarily have to come from the same supplier. Modularity creates choices, while integration determines whether those choices work together. commercetools.com

The business case needs more precision than the definition.

“We need greater agility” is difficult to evaluate. “Our merchandising team cannot change search ranking rules without entering the platform release queue” gives the project a recognizable boundary.

Before approving a replacement, ask the team to document a recent change that was unnecessarily difficult. Follow it from request to release. Identify where it waited, which systems it touched, and why the existing approach could not accommodate it.

Sometimes the investigation supports architectural change. Sometimes it reveals missing permissions, weak tooling, or an unresolved ownership problem.

That is useful information either way. A modernization budget should buy a better operating capability, and the team needs a credible explanation of how the proposed work will produce it.

Observed business constraintFirst option to investigateEvidence needed before expanding scopeCampaign content waits for engineering releasesPublishing workflow improvements or a separate content capabilityWhere publishing delays occur and which dependencies cause themMerchandisers cannot improve product discoverySearch configuration changes or a specialist search serviceQuery failures, relevance gaps, and merchandising requirementsNew storefront experiences are difficult to buildA headless storefrontWhether existing backend APIs support the required journeysPickup promises frequently prove inaccurateInventory and reservation workflowsWhere availability becomes stale or reservations failSeveral core capabilities block separate roadmapsBroader composable architectureDefined service boundaries, accountable teams, and funded operations

The table is a proposed evaluation framework, not a requirement to follow one migration sequence. Its purpose is to keep the scope connected to the problem.

Decide Whether Headless Solves Enough

The composable commerce vs headless discussion becomes useful when it changes the scope of a project.

Headless commerce separates the customer-facing experience from backend commerce functionality. Composable commerce extends modularity into business capabilities. A retailer can therefore have a custom storefront while still depending on a largely unified backend. commercetools.com

Suppose a retailer needs different shopping experiences for consumers and business accounts. If the existing backend already handles the required pricing, account rules, and transactions, a frontend change may address much of the need.

Now consider a business whose promotion logic repeatedly conflicts with account pricing and order processing. A new storefront alone would leave those dependencies in place.

The distinction should emerge from requirements. Ask which rules need to change, where those rules currently live, and whether the proposed architecture actually gives the responsible team control over them.

There is little value in purchasing backend flexibility when the business mainly needs better publishing tools. Equally, a visual redesign is unlikely to resolve a constraint buried in fulfillment logic.

Evaluate Platforms Through a Complete Customer Journey

A composable commerce platform should be evaluated through the retailer’s difficult transactions, including the exceptions that a standard demonstration can easily omit.

Consider an illustrative journey: a customer buys a discounted item for store pickup, applies loyalty credit, then cancels after the store has started preparing the order.

That scenario raises concrete questions. Which system owns the promotion calculation? When is inventory reserved? What changes when preparation begins? Who restores the loyalty credit? How does the customer learn that the cancellation is complete?

The evaluation should trace those responsibilities across the proposed stack.

API availability is only part of the assessment. Teams also need to understand how errors are reported, what happens when a request is repeated, and how support staff investigate a transaction without manually searching every vendor dashboard.

For example, Stripe documents idempotency keys as a mechanism for retrying supported requests without accidentally repeating an operation. That is a useful payment integration capability, but a retailer still needs to design and verify the behavior of the wider order journey. docs.stripe.com

Ask vendors to demonstrate a failure as well as a successful purchase. A delayed response can reveal more about operational fit than another polished storefront.

Make Omnichannel Promises Testable

A composable commerce omnichannel strategy needs explicit rules for what customers are promised across the website, app, and store.

Consider pickup availability. Showing an item as available is a claim about the retailer’s ability to fulfill an order. The architecture must account for reservations, store activity, delayed updates, and cancellations before that claim becomes dependable.

Imagine a store losing connectivity while its associates continue selling products. The digital channel needs a deliberate policy for that store’s availability. Depending on the business, the policy might reduce the quantity offered online, temporarily suspend pickup promises, or require confirmation before accepting an order.

These are business choices with technical consequences. They belong in the design discussion before teams agree on interfaces.

The following acceptance checks are illustrative starting points. Each retailer should adapt them to its transaction rules and operating model.

Scenario to testExpected behavior to defineEvidence to inspectA customer repeats checkout after a timeoutThe same purchase attempt does not create an unintended duplicate order or paymentCorrelated order and payment recordsA store’s inventory updates stop arrivingAvailability follows an agreed stale-data policyUpdate age, customer-facing promise, and alertsA cancellation arrives after preparation beginsThe request follows a defined exception workflowOrder history and staff instructionsA promotion changes while items remain in a cartThe customer receives a consistent, explainable price decisionPricing rule version and checkout resultAn event is delivered more than onceReprocessing does not repeat the business actionEvent processing records and resulting stateA new capability is withdrawnTraffic and affected data follow a rehearsed recovery procedureRouting records and reconciliation results

A shared API can make a capability accessible to several channels. The retailer still has to decide what consistent behavior means for the people using them.

Budget for the Work Between Products

A useful cost model should distinguish implementation from continuing operation.

Implementation includes data mapping, integration development, test environments, migration tooling, and changes to staff workflows. Continuing operation includes monitoring, incident response, vendor updates, reconciliation, and support.

Build the estimate around named responsibilities. “Integration maintenance” is too vague to tell a finance team what it is funding. Maintaining the product feed, handling failed inventory updates, and investigating payment discrepancies are recognizable activities with owners.

Include coexistence costs as well. During a staged migration, old and new systems may both require licenses, support, and engineering attention. The financial plan should show what allows the old capability to be retired.

This is where procurement deserves more involvement than simply comparing subscription prices. Ask about data export, API changes, support escalation, and contract exit conditions. A component may be technically replaceable while remaining expensive to remove because so many business processes depend on its data model.

Flexibility has value when the organization can use it. The budget should account for the people and processes that make that possible.

Give the First Release a Clear Stopping Point

An incremental migration should produce an independently useful result.

Microsoft describes the strangler fig pattern as replacing parts of a legacy system gradually while the remaining functionality continues to operate. Its guidance also identifies limitations: the approach requires suitable integration or interception points and may be inappropriate when the original system must be retired quickly. Microsoft Learn

For a commerce project, apply that principle to a defined capability and a manageable set of transactions.

Before development begins, agree on what must be true before traffic expands. For a search change, that could include relevant results for priority queries, acceptable response times, and dependable product updates. For a transaction capability, reconciliation deserves particular attention.

Recovery planning should address data as well as routing. Sending customers back to an older service does not resolve transactions that the new service has already accepted.

The first release should also have a business review. Did it remove the original constraint? Can the responsible team now make the intended changes? How much operational work did it introduce?

Those answers determine whether the next capability deserves investment.

Choose a Delivery Partner by the Evidence It Can Explain

A company describing itself as a leader in composable commerce should be able to support that positioning with relevant delivery evidence. The phrase itself tells a buyer little about suitability.

Ask for an example with comparable operational constraints. A storefront launch and a migration involving store inventory, account pricing, and order reconciliation are different assignments.

Useful discussions go beyond architecture diagrams. Who owned cross-system incidents? What happened when a supplier changed an API? How was the migration verified? Which responsibilities remained with the client after launch?

When evaluating composable commerce services, make those responsibilities visible in the proposed scope. Discovery, integration, migration, testing, and production support should have clear deliverables and ownership.

A delivery proposal is easier to assess when it identifies uncertain assumptions. If access to a legacy system remains unresolved, the plan should explain how that uncertainty affects sequencing and cost.

Buyers need enough detail to distinguish a feasible delivery approach from an attractive description of the destination.

Read Industry Announcements Against Your Own Roadmap

Following composable commerce news is more useful when new announcements are compared with a stable understanding of architectural tradeoffs.

A new connector might reduce work, but only if it supports the retailer’s required operations and exception cases. An AI feature might improve discovery, but the team still needs to understand which data it accesses and what actions it can perform.

Bring each announcement back to a practical question: does it remove a constraint the business has already identified?

If the answer is unclear, it belongs in an evaluation backlog. It does not yet belong in the migration scope.

FAQ

Does a retailer need to build every component itself?

No. The evaluation should distinguish capabilities the business can buy from those that require custom development. Even when most components are purchased, the retailer needs accountable ownership of integration behavior, data contracts, and production operations.

Who should own a problem that crosses several vendors?

Assign an internal service owner or an explicitly accountable delivery partner to coordinate investigation. Individual suppliers can support their products, but the retailer needs someone responsible for following the affected customer transaction across the full journey.

Should launch dates follow the marketing calendar?

The commercial calendar should inform release planning, especially around peak trading periods. However, the team should agree on acceptance conditions before setting the final cutover commitment. An unresolved reconciliation issue needs a decision, even when the campaign assets are ready.

Is composable commerce the same as microservices?

The terms describe different concerns. Composable commerce concerns how business capabilities are selected and assembled. Microservices concern how software is divided into independently operated services. Counting services alone does not establish whether a retailer can replace a business capability economically.

Can a retailer remain partly composable?

Yes. A retailer can retain a core platform while using separate capabilities where there is a clear business case. The relevant question is whether that arrangement supports the roadmap at an acceptable operating cost.

What is the strongest sign that further migration should pause?

Pause when the team cannot explain whether the previous release improved the intended business capability, or cannot reliably operate what it has already introduced. Resolve that uncertainty before increasing the number of dependencies.

The next architecture decision should follow evidence from the running business. A retailer that can name the constraint, test the proposed change, and assign responsibility for its consequences has a sound basis for proceeding.