ChatGPT answers, unedited

If I were the lead developer at a large retailer with many storefronts, my default choice would be commercetools—especially if the goal is a genuinely headless/composable architecture rather than simply putting a custom frontend on top of a traditional commerce suite.

My shortlist

Why I'd pick commercetools

For a large retailer, the important question isn't merely "Does it have headless APIs?" Almost all the serious platforms do. The question is how well the platform becomes a shared commerce backend for dozens of experiences without forcing those experiences into the same implementation model.

commercetools is particularly strong here. Its current enterprise offering explicitly targets unified commerce across web, mobile, stores, social and marketplaces, while supporting multiple brands/stores and large catalogs on a cloud-native architecture. Commercetools Commercetools

I'd structure it roughly like:

                    ┌── Brand A Web
                    ├── Brand B Web
                    ├── Brand C Web
                    ├── Mobile Apps
                    ├── Marketplace
                    ├── In-store / Kiosks
                    └── Other channels
                              │
                       API / Experience Layer
                              │
                 ┌────────────┴────────────┐
                 │                         │
             Commerce                 Experience
          commercetools                   CMS
                 │                         │
       ┌─────────┼─────────┐              │
       │         │         │              │
    Catalog    Cart     Checkout       Personalization
       │         │         │              │
       └─────────┴─────────┴──────────────┘
                       │
              ERP / OMS / PIM / WMS

The key architectural advantage is that storefronts don't have to be the unit of commerce architecture. You can establish shared product, pricing, cart, inventory, promotion, customer and order capabilities while allowing each brand/channel to evolve independently.

When I'd choose Salesforce instead

If your retailer already has a substantial Salesforce footprint—CRM, Marketing Cloud, Service Cloud, Data Cloud, etc.—I'd seriously consider Salesforce Commerce Cloud instead.

Salesforce's current Composable Storefront is explicitly designed around headless commerce, with its PWA Kit, Managed Runtime and Commerce APIs. Its APIs cover shopper functions such as browsing, carts and checkout as well as administrative capabilities such as products, orders, inventory and customers. Developer

It's also attractive for a retailer that wants a hybrid migration. Salesforce supports running traditional storefront functionality alongside headless Composable Storefront components, which can substantially reduce the risk of a big-bang replatform. Developer

So my decision rule would be:

• Greenfield / maximum architectural independence → commercetools
• Already heavily invested in Salesforce → Salesforce Commerce Cloud
• Adobe ecosystem is strategically important → Adobe Commerce
• Operational simplicity and rapid rollout across many relatively independent stores → Shopify Plus
• Want API-first/headless but less composable complexity → BigCommerce

One architectural warning

I wouldn't create one frontend application per storefront unless the brands genuinely need independent technology stacks.

For 20–100 storefronts, I'd want a shared storefront platform with configuration/tenant boundaries:

                    Shared Storefront Platform
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
      storefront A        storefront B        storefront C
       config/theme        config/theme        config/theme
          │                   │                   │
          └───────────────────┼───────────────────┘
                              │
                       Shared APIs/SDKs
                              │
                       Commerce Platform

That gives you centralized engineering, observability, CI/CD, security and performance improvements while preserving brand-level autonomy.

If I had to make the platform decision today, without knowing anything else about your retailer, I'd put commercetools first and Salesforce Commerce Cloud second. The deciding factor would be whether your organization values maximum composability or integration with an existing enterprise Salesforce estate. Commercetools Developer

If you tell me roughly how many storefronts/brands, B2C vs. B2B, countries, SKU count, and your existing ERP/PIM/OMS, I can narrow this down to a concrete target architecture and platform recommendation.

If your retailer already has a substantial Salesforce footprint—CRM, Marketing Cloud, Service Cloud, Data Cloud, etc.—I'd seriously consider Salesforce Commerce Cloud instead.

Salesforce's current Composable Storefront is explicitly designed around headless commerce, with its PWA Kit, Managed Runtime and Commerce APIs. Its APIs cover shopper functions such as browsing, carts and checkout as well as administrative capabilities such as products, orders, inventory and customers.

For a large retailer with many storefronts, I’d make commercetools the default choice if your organization genuinely has the engineering maturity to operate a composable platform.

commercetools is purpose-built as an API-first, headless commerce platform, and its current enterprise offering is explicitly aimed at running commerce across multiple channels and touchpoints from a shared foundation. commercetools.com

My shortlist

Why I'd lean commercetools

For your use case, I'd optimize for one commerce platform → many independently deployable experiences, rather than treating every storefront as a separate commerce implementation.

A good target architecture would look roughly like:

                       ┌── Storefront A
                       ├── Storefront B
Customers ── CDN ──────┼── Storefront C
                       ├── Mobile App
                       ├── Marketplace
                       └── In-store / kiosk

                              │
                         Experience/API
                              │
                 ┌────────────┴────────────┐
                 │                         │
          commercetools              CMS / PIM
                 │
       ┌─────────┼──────────┐
       │         │          │
    Catalog    Pricing    Promotions
       │         │          │
       └─────────┼──────────┘
                 │
       ┌─────────┼─────────────┐
       │         │             │
      OMS       ERP          Payments

The key architectural property is that storefronts aren't the system of record. They consume commerce capabilities through APIs, so you can launch or retire brands, regions, channels, and experiences without cloning the commerce backend.

That is exactly where commercetools' headless/API-first model is attractive. commercetools.com

But don't automatically choose commercetools

This is the important caveat.

If you're a large retailer but your storefronts are primarily regional variations of the same business, I'd seriously consider Shopify Plus instead. Shopify supports headless storefronts through its Storefront API and has centralized organization management plus expansion stores. commercetools.comhelp.shopify.comwww.shopify.com

Shopify Plus currently supports a main store plus nine expansion stores under the standard arrangement, with additional-store options, and its headless stack can be hosted independently. help.shopify.com

So I'd frame the decision this way:

Choose commercetools if:

• You have 10s–100s of storefronts/channels
• Multiple brands have materially different commerce rules
• Pricing/promotions/catalogs vary substantially by market
• You expect to compose your own PIM, CMS, search, OMS, personalization, etc.
• You have a strong platform engineering organization
• Avoiding vendor lock-in is strategically important
• Commerce is becoming an internal platform rather than simply an ecommerce site

Choose Shopify Plus if:

• Most storefronts are variations of a common commerce model
• You want dramatically less platform engineering/operations
• Speed to market is more important than maximum architectural freedom
• Your differentiating investment is primarily in the frontend experience
• You want merchants/operations teams to have a mature admin experience out of the box

Shopify itself now explicitly positions Plus as a composable foundation where the transactional core stays managed while teams customize the experience layer. www.shopify.com

What I'd do as lead dev

I wouldn't make "headless" the primary architectural decision. I'd establish these principles first:

1. Single canonical product/customer/order model
2. Storefronts are disposable
3. No business logic duplicated in frontend applications
4. API-first commerce capabilities
5. Centralized identity, observability, feature flags and experimentation
6. Independent deployment of each storefront
7. Explicit tenant/brand/market configuration
8. Event-driven integration with ERP/OMS/PIM
9. Platform team owns the commerce primitives; product teams own experiences
10. Don't make everything microservices just because you can

That last point matters. Composable commerce can turn into a very expensive distributed-systems project if you decompose capabilities that don't actually need independent ownership or scaling. Even Shopify's current guidance acknowledges that composability is worthwhile when it solves a real bottleneck rather than simply because it's architecturally fashionable. commercetools.comhelp.shopify.comwww.shopify.com

Bottom line: for a large retailer with genuinely complex multi-store/multi-brand requirements, I'd shortlist commercetools first and Shopify Plus second. If your main problem is operational scale and storefront proliferation, Shopify Plus may win. If your main problem is architectural flexibility and radically different commerce models across the organization, I'd choose commercetools.

For a large retailer with many storefronts, my default recommendation would be commercetools.

commercetools.com

The reason isn't simply that it's "headless." It's that it is particularly well suited to treating commerce as a shared platform underneath many independently evolving experiences.

My shortlist

Why I'd choose commercetools

For your architecture, I'd want something like:

                         ┌── Storefront A
                         ├── Storefront B
                         ├── Storefront C
                         ├── Mobile App
                         ├── Marketplace
                         └── In-store / Kiosk
                                  │
                         ┌────────▼────────┐
                         │ API / Experience│
                         │    Layer        │
                         └────────┬────────┘
                                  │
              ┌───────────────────▼───────────────────┐
              │            commercetools               │
              │                                        │
              │ Catalog │ Pricing │ Cart │ Promotions │
              │ Orders  │ Checkout│ Inventory │ etc. │
              └───────────────────┬───────────────────┘
                                  │
                 ┌────────────────┼─────────────────┐
                 ▼                ▼                 ▼
               ERP              PIM               OMS

The important architectural property is that the storefront isn't the system of record. You can create multiple experiences over the same commerce capabilities, while allowing individual brands/regions to diverge where necessary.

commercetools explicitly supports multiple brands and stores, regional catalogs, currencies and languages, and describes its platform as API-native and modular. Its retail offering also calls out multi-brand/multi-catalog operations and a single backend for global/local experiences. commercetools commercetools

The big architectural decision

I would not create one giant "universal storefront application."

Instead, I'd establish a shared storefront platform with independently deployable storefronts:

• Shared design system
• Shared authentication/session infrastructure
• Shared observability
• Shared API/client SDKs
• Shared commerce domain services
• Shared experimentation/personalization infrastructure
• Storefront-specific composition and branding
• Region/brand-specific configuration

That gives you platform standardization without forcing every brand onto the same release cycle.

When I'd pick Salesforce instead

If your retailer is already deeply invested in Salesforce CRM, Marketing Cloud, Service Cloud, loyalty, and customer data, I'd seriously consider Salesforce Commerce Cloud.

salesforce.com

Salesforce supports headless APIs, arbitrary frontend frameworks, B2C/B2B experiences, and multiple sites/storefronts. Its documentation specifically describes configurations ranging from one site/multiple storefronts to multiple sites/multiple storefronts. Salesforce Salesforce

I'd choose it over commercetools when Salesforce ecosystem integration is a strategic requirement, rather than because its headless capabilities are inherently superior.

When I'd pick Shopify Plus

I'd pick Shopify Plus if your priority is:

"We need many stores, excellent commerce operations, fast delivery, and don't want our engineering organization to become a commerce-platform company."

That's a very legitimate choice.

But for a large retailer where engineering wants to own the experience architecture and expects extensive integration, complex pricing/catalog models, multiple business units, and potentially dozens of storefronts, I'd lean commercetools.

My recommendation

If I were the lead developer making the architectural decision, I'd rank them:

1. commercetools — best strategic fit
2. Salesforce Commerce Cloud — if Salesforce is already central
3. Shopify Plus — if operational simplicity/time-to-market dominates
4. Adobe Commerce — if Adobe is already deeply embedded
5. BigCommerce — strong but less compelling for extreme enterprise complexity

The crucial caveat: don't select the commerce platform in isolation. For a retailer of significant scale, I'd evaluate the combination of commerce engine + PIM + search + CMS + OMS + pricing/promotions + identity + CDN/edge + frontend platform. The commerce engine should be one component of the architecture, not the architecture itself.

If you give me roughly number of storefronts, countries, SKUs, order volume, B2C/B2B mix, and whether you already use Salesforce/Adobe/SAP, I can give you a much more concrete enterprise reference architecture and platform recommendation.

If I were the lead dev at a large retailer with many brands/regions/storefronts, my default choice would be commercetools—assuming the organization is genuinely ready for a composable architecture.

My ranking

Why I'd pick commercetools

The biggest reason is multi-storefront architecture without turning every new brand or country into another technology stack.

commercetools explicitly supports native multi-site deployments, allowing different storefronts to have their own catalogs/product selections, pricing, currencies, languages, inventory and promotions while sharing underlying commerce capabilities. commercetools commercetools

That's particularly attractive for a retailer where you might eventually have:

                    ┌── Brand A / US
                    ├── Brand A / CA
                    ├── Brand A / EU
                    ├── Brand B / US
Commerce Platform ──┼── Brand B / EU
                    ├── Outlet / US
                    ├── Marketplace
                    ├── Mobile app
                    └── In-store / kiosk

Rather than:

Storefront A → Commerce Instance A
Storefront B → Commerce Instance B
Storefront C → Commerce Instance C
...

You get a shared commerce capability layer with independently deployable experience layers.

commercetools is also deliberately API-first and modular, so search, CMS, personalization, payments, tax, OMS, etc. can be selected independently rather than forcing the entire retailer onto one vendor's stack. commercetools commercetools

Where Salesforce could beat it

I'd seriously consider Salesforce Commerce Cloud if the retailer already has substantial Salesforce investment.

Salesforce's current Composable Storefront architecture separates the frontend from commerce logic and provides PWA Kit + Managed Runtime, while its APIs cover products, catalogs, baskets, promotions, inventory, shipping and billing. It also supports multiple storefronts/sites. Developer Salesforce

That's a compelling choice if your architecture looks like:

Salesforce CRM + Marketing + Service + Commerce + customer data

rather than a best-of-breed composable stack.

Salesforce also has a particularly attractive migration story: its current architecture supports hybrid storefronts, so you don't necessarily have to headless-rebuild the entire retailer at once. Salesforce

The architecture I'd aim for

For a large retailer, I wouldn't make the commerce platform responsible for everything:

                    EXPERIENCE LAYER
       ┌──────────────┬──────────────┬──────────────┐
       │ Brand A Web  │ Brand B Web  │ Mobile / App │
       └──────────────┴──────────────┴──────────────┘
                          │
                    API / BFF Layer
                          │
       ┌──────────────────┼───────────────────┐
       │                  │                   │
  Commerce           CMS / Content       Search / PLP
(commercetools)          │                (Algolia/etc.)
       │                  │
       ├── Catalog        │
       ├── Pricing        │
       ├── Cart           │
       ├── Promotions     │
       ├── Inventory      │
       └── Checkout       │
                          │
       ┌──────────────────┼───────────────────┐
       │                  │                   │
      PIM                OMS                 ERP
       │                  │                   │
   Product data       Fulfillment          Finance

The key architectural decision is to make storefront identity/configuration a first-class concept rather than cloning an application for every brand.

I'd want each storefront to specify things like:

• catalog/product assortment
• price books
• currency
• locale
• market
• promotions
• fulfillment options
• CMS space
• feature flags
• theme/design system
• payment methods
• tax configuration

while the underlying commerce capabilities remain shared.

One important caveat

I wouldn't choose commercetools simply because "headless = modern." Composable commerce transfers significant responsibility to your engineering organization. The platform gives you flexibility, but you now own the integration architecture.

If your team isn't equipped to operate that complexity, Salesforce or Shopify Plus can produce a better business outcome despite being less architecturally pure.

So my decision rule would be:

Strong engineering organization + many differentiated storefronts + long-term need for flexibility → commercetools.
Salesforce-heavy enterprise → Salesforce Commerce Cloud.
Standardized stores + prioritize speed/operational simplicity → Shopify Plus.
SAP-centric enterprise → SAP Commerce Cloud.

For the specific scenario you described—large retailer + headless + many storefronts—I'd put commercetools at #1, with Salesforce as the strongest alternative. commercetools commercetools

If you're evaluating this for an actual enterprise RFP, the next step I'd recommend is comparing commercetools vs Salesforce vs Shopify Plus across multi-tenancy, catalog/pricing, checkout, promotions, PIM/OMS integration, deployment model, developer experience, TCO, and peak-event scalability rather than comparing generic "headless" feature lists.

commercetools is also deliberately API-first and modular, so search, CMS, personalization, payments, tax, OMS, etc. can be selected independently rather than forcing the entire retailer onto one vendor's stack. commercetools commercetools

Where Salesforce could beat it

I'd seriously consider Salesforce Commerce Cloud if the retailer already has substantial Salesforce investment.

Salesforce's current Composable Storefront architecture separates the frontend from commerce logic and provides PWA Kit + Managed Runtime, while its APIs cover products, catalogs, baskets, promotions, inventory, shipping and billing. It also supports multiple storefronts/sites. Developer Salesforce

That's a compelling choice if your architecture looks like:

Salesforce CRM + Marketing + Service + Commerce + customer data

rather than a best-of-breed composable stack.

Salesforce also has a particularly attractive migration story: its current architecture supports hybrid storefronts, so you don't necessarily have to headless-rebuild the entire retailer at once. Salesforce

The architecture I'd aim for

For a large retailer, I wouldn't make the commerce platform responsible for everything:

                    EXPERIENCE LAYER
       ┌──────────────┬──────────────┬──────────────┐
       │ Brand A Web  │ Brand B Web  │ Mobile / App │
       └──────────────┴──────────────┴──────────────┘
                          │
                    API / BFF Layer
                          │
       ┌──────────────────┼───────────────────┐
       │                  │                   │
  Commerce           CMS / Content       Search / PLP
(commercetools)          │                (Algolia/etc.)
       │                  │
       ├── Catalog        │
       ├── Pricing        │
       ├── Cart           │
       ├── Promotions     │
       ├── Inventory      │
       └── Checkout       │
                          │
       ┌──────────────────┼───────────────────┐
       │                  │                   │
      PIM                OMS                 ERP
       │                  │                   │
   Product data       Fulfillment          Finance

The key architectural decision is to make storefront identity/configuration a first-class concept rather than cloning an application for every brand.

I'd want each storefront to specify things like:

• catalog/product assortment
• price books
• currency
• locale
• market
• promotions
• fulfillment options
• CMS space
• feature flags
• theme/design system
• payment methods
• tax configuration

while the underlying commerce capabilities remain shared.

One important caveat

I wouldn't choose commercetools simply because "headless = modern." Composable commerce transfers significant responsibility to your engineering organization. The platform gives you flexibility, but you now own the integration architecture.

If your team isn't equipped to operate that complexity, Salesforce or Shopify Plus can produce a better business outcome despite being less architecturally pure.

So my decision rule would be:

Strong engineering organization + many differentiated storefronts + long-term need for flexibility → commercetools.
Salesforce-heavy enterprise → Salesforce Commerce Cloud.
Standardized stores + prioritize speed/operational simplicity → Shopify Plus.
SAP-centric enterprise → SAP Commerce Cloud.

For the specific scenario you described—large retailer + headless + many storefronts—I'd put commercetools at #1, with Salesforce as the strongest alternative.

For a large retailer with many storefronts, my default recommendation would be commercetools—unless your overriding priority is minimizing engineering and operational complexity, in which case BigCommerce or Shopify Enterprise can be better fits.

My ranking

Why I'd choose commercetools

For a retailer operating dozens or hundreds of experiences, I'd want the commerce platform to be a shared commerce capability layer, rather than treating each storefront as a separate ecommerce application.

commercetools is particularly suited to that model: it's API-first and modular, with commerce capabilities exposed independently, and explicitly targets enterprise-scale multi-channel architectures. It currently reports supporting 550+ enterprises, 140M+ SKUs and 700M+ annualized orders. commercetools.com

I'd architect it roughly like:

                    ┌─────────────────────────┐
                    │       Experience         │
                    │                          │
                    │ Brand A  Brand B  Brand C│
                    │ Web      Web      Web     │
                    │ Mobile   Mobile   Mobile  │
                    └────────────┬────────────┘
                                 │
                         Experience APIs
                                 │
              ┌──────────────────▼──────────────────┐
              │          Commerce Platform           │
              │                                      │
              │ Catalog │ Pricing │ Cart │ Checkout │
              │ Customer│ Orders  │ Promotions       │
              └──────────────────┬──────────────────┘
                                 │
              ┌──────────────────▼──────────────────┐
              │        Enterprise Integration       │
              │                                    │
              │ PIM │ ERP │ OMS │ WMS │ CRM │ Tax  │
              └────────────────────────────────────┘

The key is not creating a separate commerce backend per storefront. Instead, establish common commerce capabilities and let each brand/region/channel configure what differs.

Where BigCommerce gets interesting

I'd seriously evaluate BigCommerce if your organization wants a less ambitious composable architecture.

Its Multi-Storefront model is specifically designed to manage multiple brands, regions and customer segments from one backend, with distinct pricing, domains, catalogs and experiences. Its APIs also support custom headless storefronts. www.bigcommerce.com

That's a very attractive proposition for a retailer where:

"We need 40 storefronts, but we don't want 40 commerce implementations."

BigCommerce also has Catalyst, its Next.js/React headless framework, so your team can standardize the frontend technology while retaining a SaaS commerce backend. www.bigcommerce.com

If I were optimizing for total engineering effort rather than architectural purity, I'd probably pick BigCommerce.

Shopify Enterprise

Shopify is compelling if the organization is primarily DTC and wants the platform to absorb as much operational complexity as possible. Shopify supports headless storefronts through its API layer and offers enterprise support and high-scale infrastructure. www.shopify.com

The tradeoff is that I'd be more cautious about making Shopify the foundational commerce abstraction for a retailer with unusually complex pricing, catalog, fulfillment, B2B, organizational, or multi-brand requirements.

The decision I'd make as lead dev

I'd use this rule:

• Complex enterprise retailer + many brands/channels + significant internal engineering → commercetools
• Many storefronts + conventional retail requirements + want SaaS simplicity → BigCommerce
• DTC-first + speed/operational simplicity are paramount → Shopify
• Need extreme customization and are willing to own more infrastructure → Saleor/Medusa/Vendure
• Existing major Adobe investment → Adobe Commerce

One important architectural point: don't let "headless" become the architecture. Headless is just the separation of presentation from commerce. For a large retailer, I'd spend considerably more design effort on catalog ownership, pricing, inventory, customer identity, order orchestration, eventing, search, CMS, observability, and tenant/storefront configuration than on choosing Next.js versus another frontend framework.

If you tell me roughly how many storefronts/brands, countries, SKUs, annual orders, B2B vs B2C, and whether you already have an ERP/OMS/PIM, I can give you a much more opinionated platform choice and reference architecture.

If I were the lead dev at a large retailer with many storefronts, my default choice would be commercetools—unless your organization is already deeply standardized on Salesforce.

My ranking

Why I'd pick commercetools

For a large retailer, I'd optimize less for "which platform has the most ecommerce features?" and more for how cleanly can we operate 20–100+ storefronts without creating a giant distributed monolith.

commercetools is particularly strong here because it is designed around API-first, modular commerce, with support for multiple brands/stores, international expansion, and integration with external ERP/CRM/PIM/CMS systems. Its current platform is explicitly positioned for enterprise-scale workloads and complex multi-channel environments. commercetools.com

I'd architect it roughly as:

                    ┌── Storefront A
                    ├── Storefront B
CDN / Edge ─────────┼── Storefront C
                    ├── Mobile Apps
                    └── In-store / Other Channels
                             │
                       API / Experience Layer
                             │
        ┌────────────────────┼─────────────────────┐
        │                    │                     │
    Commerce            Search/PIM             CMS
 commercetools          Algolia/etc.         Contentful/etc.
        │
 ┌──────┼─────────┬───────────┐
 │      │         │           │
Cart  Pricing  Promotions  Checkout
 │
OMS / ERP / Inventory / Payments / Tax

The important part is that storefronts aren't individual ecommerce applications. They're thin experiences consuming shared commerce capabilities.

When I'd choose Salesforce instead

If the retailer already has substantial Salesforce investment—CRM, Marketing Cloud, customer data, service, etc.—I'd seriously consider Salesforce Commerce Cloud.

Its current Composable Storefront uses a React-based PWA Kit plus Managed Runtime, with Commerce APIs underneath, and supports combining Salesforce capabilities with third-party services. developer.salesforce.com

That's especially attractive if you want:

• shared customer identity/data
• Salesforce CRM integration
• B2B + B2C
• many regional/brand storefronts
• a managed enterprise platform
• less infrastructure for your team to own

Salesforce also supports hybrid implementations, which is valuable if you're migrating a huge retailer incrementally rather than doing a "big bang" replatform. developer.salesforce.com

Shopify Plus would be my "simplify everything" choice

Shopify Plus becomes compelling if the primary objective is getting dozens of storefronts operating with minimal platform engineering.

Shopify Plus supports expansion stores under a centralized organization, including separate stores for international markets, product lines, B2B, employees, and other purposes. help.shopify.com

The tradeoff is architectural freedom: I'd be more comfortable with Shopify if the retailer's differentiating technology is primarily above the commerce platform rather than deeply embedded in custom commerce logic.

The decision I'd make

If I'm choosing purely on architecture:

commercetools + Next.js/React storefronts + headless CMS + dedicated PIM + search + OMS + enterprise integration layer.

If we're already a Salesforce shop:

Salesforce Commerce Cloud + Composable Storefront.

If business wants the lowest operational complexity and fastest rollout:

Shopify Plus.

One important caveat: for a large retailer, I'd make the storefront model a first-class architectural decision before selecting the commerce vendor. You want a platform where adding Store #47 is largely configuration/data/branding, not another codebase and another deployment pipeline.

If you tell me roughly how many storefronts, countries, brands, SKUs, annual orders, and whether you need B2B + B2C, I can give you a much more opinionated architecture and a commercetools vs Salesforce vs Shopify decision matrix.

If I were the lead dev at a large retailer with many storefronts, my default recommendation would be commercetools—especially if you're genuinely committing to a composable/headless architecture rather than just wanting a custom frontend.

My shortlist

Why I'd lean commercetools

For a retailer with, say, 10–100+ storefronts across brands, countries, channels, or business units, I'd want the commerce backend to be a relatively clean platform service rather than something each storefront becomes tightly coupled to.

commercetools is explicitly designed around API-first, composable commerce, with support for multiple brands/stores, international expansion, web/mobile/in-store channels, and integration with ERP/CRM and other systems. commercetools.com

The architecture I'd aim for is roughly:

                         ┌──────────────────────┐
                         │     Experience       │
                         │       Layer          │
                         └──────────┬───────────┘
                                    │
        ┌──────────────┬────────────┼─────────────┬──────────────┐
        ▼              ▼            ▼             ▼              ▼
     Brand A        Brand B      Brand C       Mobile        In-store
    storefront     storefront   storefront       app          kiosk
        │              │            │             │              │
        └──────────────┴────────────┴─────────────┴──────────────┘
                                    │
                              API / BFF layer
                                    │
                 ┌──────────────────┼──────────────────┐
                 ▼                  ▼                  ▼
          ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
          │ commercetools│   │    CMS      │   │   Search    │
          │   Commerce   │   │             │   │             │
          └─────────────┘   └─────────────┘   └─────────────┘
                 │
       ┌─────────┼─────────┬──────────────┐
       ▼         ▼         ▼              ▼
      ERP       OMS       PIM          Pricing/Promo

The important architectural decision is not to make each storefront its own application/platform. Instead, I'd build a shared retail experience platform with:

• shared design system/components
• shared frontend infrastructure
• tenant/store configuration
• centralized identity
• centralized observability
• shared commerce APIs
• per-store catalog/price/promotion rules
• per-market localization/tax/payment configuration
• independently deployable storefronts

That lets Brand A and Brand B have radically different experiences without duplicating the underlying commerce capabilities.

When I'd choose Salesforce instead

I'd put Salesforce Commerce Cloud at #1 if your retailer already has substantial investment in Salesforce—particularly CRM, customer data, loyalty, service, or Salesforce Order Management.

Salesforce's current headless architecture supports Commerce APIs, a React-based PWA Kit, and Managed Runtime. Its platform also explicitly supports multiple sites from a shared codebase, including different domains, locales, and catalogs. developer.salesforce.com

So if the organization says:

"We want headless, but we also want Salesforce to remain the strategic customer/commerce platform."

I'd choose Salesforce over commercetools.

The bigger architectural question

I wouldn't select the platform based primarily on "does it support headless?"

At your scale, I'd score vendors on:

1. Multi-brand/multi-market modeling
2. Catalog and price-list isolation/sharing
3. Promotion complexity
4. Inventory/OMS integration
5. API quality and rate limits
6. Deployment independence
7. Localization/currency/tax
8. B2B requirements, if applicable
9. Operational resilience during peak events
10. Ability to avoid vendor lock-in
11. Total cost at your actual order/API volume
12. How easily another storefront can be launched

That last one is particularly important. I'd want the marginal cost of launching storefront #37 to be mostly configuration and content, not another 12-month engineering project.

My recommendation

If you're a technically mature retailer building for the next 5–10 years:

commercetools + Next.js/React storefront platform + enterprise CMS + dedicated search + PIM + OMS + API/BFF layer

I'd favor that over putting all commerce, CMS, frontend, search, and customer experience into one vendor.

If you're already heavily invested in Salesforce, I'd instead go:

Salesforce Commerce Cloud + Composable Storefront + shared frontend platform

Salesforce specifically supports decoupled storefronts and allows third-party services such as search and CMS to be composed around its Commerce APIs. developer.salesforce.com

One caveat: composable gives you much more architectural freedom, but it also means you own the integration architecture. That's the tradeoff I'd take at a large retailer with a strong engineering organization; it may be unnecessary complexity for a smaller team. www.salesforce.com

If you tell me roughly number of storefronts, countries, annual orders/GMV, B2C vs B2B, existing ERP/OMS/PIM/CMS, and whether Salesforce/Adobe/Shopify is already entrenched, I can give you a much more concrete platform + reference architecture recommendation.

For a large retailer with many storefronts, I would not start with “which commerce platform has the most features?” I would start with which platform gives you the right operating model for dozens of brands, regions, channels, and teams.

For that scenario, my shortlist would be:

www.ciopages.comcommercetools.com

My default recommendation: commercetools + composable stack

For a retailer running many storefronts (for example: multiple brands, countries, banners, marketplaces, mobile apps, kiosks), I would lean toward:

• Commerce engine: commercetools
• Frontend: React/Next.js or similar
• CMS: headless CMS (Contentful, Sanity, Adobe Experience Manager, etc.)
• Search: dedicated search engine (Algolia, Coveo, Elasticsearch/OpenSearch)
• Pricing/promotions: commerce services + specialized services where needed
• OMS: existing enterprise OMS or best-of-breed OMS
• Identity/CDP: enterprise identity + customer data platform
• API gateway/event backbone: to decouple storefronts from backend systems

The reason: you want one commerce capability layer powering many experiences, not many storefronts becoming many forks of the same application. A MACH-style architecture (microservices, API-first, cloud-native, headless) is designed around that model. commercetools.com

A good target architecture looks like:

                 Storefronts
     --------------------------------
     Web A     Web B     Mobile     POS
       |         |         |         |
       +---------+---------+---------+
                    |
             Experience APIs
                    |
       --------------------------------
       |        Commerce Services     |
       |                              |
       | Catalog | Cart | Checkout    |
       | Pricing | Promo | Customer   |
       --------------------------------
                    |
       --------------------------------
       | ERP | OMS | PIM | Tax | ERP |
       --------------------------------

Where I would choose something else

Choose Salesforce Commerce Cloud if:

• Your enterprise already runs heavily on Salesforce CRM, Service Cloud, Marketing Cloud, or Data Cloud.
• Customer identity, personalization, and sales/service integration are more important than maximum backend modularity.
• You want a supported enterprise path rather than assembling many components.

Salesforce supports headless/composable storefront approaches through its commerce APIs and composable storefront tooling. www.salesforce.com

Choose Adobe Commerce if:

• You have very complex catalog rules.
• You have significant B2B workflows.
• You already have Magento expertise internally.
• You need deep customization and control.

Adobe can support headless architectures, but it originated as a more traditional commerce platform, so you need to be deliberate about how much of the stack you decouple. commercetools.comwww.salesforce.combemeir.com

Choose Shopify Plus if:

• Your priority is speed and reducing platform operations.
• Most stores are DTC.
• Your teams do not want to own a large distributed commerce platform.

Shopify has expanded its headless capabilities, but you generally accept more platform constraints compared with a pure composable approach. www.shopify.com

The questions I would ask before approving a platform

As lead dev, I would force these decisions early:

1. How many storefronts?
   • 5 brands is different from 50 regional storefronts.

2. Do they share a catalog?
   • Shared product model → composable shines.
   • Completely different businesses → simpler SaaS may win.

3. Who owns pricing?
   • Enterprise retailers often underestimate pricing complexity.

4. Do you want independent release cycles?
   • If Brand A can deploy without risking Brand B, composable architecture helps.

5. How large is the platform engineering team?
   • A composable stack is powerful, but you become responsible for integration architecture, observability, testing, and reliability.

My ranking for a large retailer with many storefronts

1. commercetools — best long-term architecture if you have the engineering maturity
2. Salesforce Commerce Cloud — best if Salesforce is the enterprise backbone
3. Adobe Commerce — best for complex commerce rules and customization
4. Shopify Plus — best when speed and simplicity beat architectural freedom

For a retailer with a serious platform engineering team, I would likely build a composable commerce platform around commercetools, with a strong internal commerce platform layer that exposes reusable capabilities to every storefront. commercetools.com

For a large retailer with many storefronts, I would generally bias toward a true composable/headless commerce platform, but the best choice depends on whether your priority is architectural freedom, operational simplicity, or ecosystem integration.

My shortlist would be:

My recommendation for a large retailer

If I were the lead developer designing a 10+ storefront architecture, I would likely choose:

Option A — Enterprise composable (my default recommendation)

commercetools + modern frontend stack

Example architecture:

                 Storefronts
                     |
        --------------------------------
        |        |        |             |
      Web     Mobile   Kiosk       Marketplace
        |
        v
  Experience Layer
 (Next.js / React / native apps)
        |
        v
  Commerce Platform
 (commercetools)
        |
 ---------------------------------
 |       |        |        |       |
PIM    OMS     Search   CMS    Payments

You get:

• One commerce backend powering many brands
• Independent storefront releases
• Regionalization
• Shared inventory/pricing/promotions logic
• Easier experimentation
• Ability to replace CMS/search/PIM without replatforming

This aligns well with MACH-style architecture (Microservices, API-first, Cloud-native, Headless). commercetools.com

Option B — If your company is Salesforce-heavy

Choose Salesforce Commerce Cloud.

I would not underestimate the value of having:

• CRM identity
• loyalty
• customer service
• marketing automation
• commerce

all connected. For many retailers, that operational advantage outweighs architectural purity. www.salesforce.com

Option C — If you have a very complex merchandising organization

Adobe Commerce can still be the right call, especially where:

• catalog rules are extremely complicated
• B2B and B2C coexist
• ERP integration dominates the problem
• merchandising teams need mature workflows

experienceleague.adobe.com

The architecture matters more than the vendor

For many storefronts, I would avoid the common mistake of making the commerce platform also be:

• CMS
• search engine
• recommendation engine
• customer data platform
• experimentation platform
• frontend framework

A scalable retailer architecture usually looks more like:

• Commerce core: commercetools / Salesforce / Adobe
• Frontend: React/Next.js, native apps, in-store apps
• CMS: Contentful, Adobe Experience Manager, Sanity, etc.
• Search: Algolia, Elasticsearch/OpenSearch, Coveo, etc.
• PIM: Akeneo, Salsify, inRiver, etc.
• OMS: dedicated order orchestration
• CDP/CRM: customer intelligence layer

The questions I’d ask before selecting

1. How many storefronts?
   • 5 brands?
   • 50 countries?
   • thousands of dealer portals?

2. Do storefronts share:
   • catalog?
   • inventory?
   • pricing?
   • promotions?
   • customer accounts?

3. Is the business trying to differentiate digitally, or mainly digitize existing retail?

4. How large is the platform engineering team?
   • 5 engineers → avoid over-composable
   • 20+ engineers → composable becomes much more attractive

5. Are you replacing an existing platform?
   • SAP Hybris?
   • Magento?
   • Salesforce?
   • custom commerce?

For a large retailer with a strong engineering organization and many storefronts, my first evaluation would be commercetools vs Salesforce Commerce Cloud, with Adobe Commerce as the contender if catalog/B2B complexity is the dominant requirement. www.ciopages.com

If I were the lead dev at a large retailer with many storefronts, my default choice would be commercetools—unless your organization strongly prioritizes speed-to-market and minimizing engineering ownership, in which case I'd choose Shopify Plus.

My ranking

Why I'd pick commercetools

For a large retailer, the important question isn't merely "can it do headless?" It's how well does the commerce domain model map to dozens of storefronts, brands, countries, catalogs, pricing regimes, inventories and customer experiences?

commercetools is designed around exactly that composable model. Its Stores and Channels allow different shopping contexts to share resources while maintaining distinct experiences, pricing and inventory contexts. docs.commercetools.com

It also gives you a genuinely API-first architecture rather than treating headless as an alternative presentation layer. The platform exposes commerce capabilities as APIs and is explicitly designed around cloud-native, modular, MACH principles. commercetools.com

For your architecture, I'd roughly envision:

Storefronts
→ Next.js / React
→ shared design system + storefront platform
→ API gateway / BFF layer
→ commercetools
→ PIM / CMS / search / pricing / promotions / OMS / payments
→ ERP, WMS, CRM, loyalty, etc.

That gives you a common commerce core while allowing Store A, Store B, international Store C, mobile, kiosks, or future channels to evolve independently.

Where Shopify Plus wins

I'd seriously consider Shopify Plus if your primary goal is:

"We need 20–100 storefronts, but we don't want to become a commerce-platform engineering company."

Shopify supports multiple custom storefronts connected to a common commerce backend, and its enterprise offering supports headless, traditional, and modular implementations. www.shopify.com

That's a huge advantage operationally. You get mature checkout, payments, merchandising, admin tooling, ecosystem integrations, etc., without your team having to assemble as much of the commerce infrastructure.

The tradeoff is architectural control. If you're a sophisticated retailer with unusual pricing, promotions, inventory allocation, fulfillment, B2B/B2C convergence, multiple brands, or significant domain-specific commerce logic, commercetools gives your engineering organization more room to model the business rather than adapt the business to the platform.

BigCommerce is the interesting middle option

BigCommerce Enterprise deserves a serious POC. Its current offering combines headless APIs with native multi-storefront management: different brands/regions can have distinct catalogs, currencies, pricing, domains, templates, etc., while being administered through one backend. www.bigcommerce.com

So I'd characterize the choices as:

• commercetools: "Commerce is a strategic technology platform; we want maximum architectural freedom."
• Shopify Plus: "Commerce is a business capability; we want the platform to handle as much as possible."
• BigCommerce: "We want headless + multi-store without taking on quite as much composable-platform complexity."

What I'd actually do

For a large retailer, I wouldn't select based on feature checklists. I'd run a 4–6 week architecture POC around the hardest workflows:

1. One shared product catalog → 5+ storefronts
2. Store-specific assortment
3. Store/country-specific pricing
4. Promotions and coupons
5. Inventory by location
6. Customer identity/account
7. Cart → checkout → payment
8. Order → OMS → fulfillment
9. Search/merchandising
10. CMS/content localization
11. Peak-event performance
12. Disaster recovery and observability
13. Developer experience and CI/CD
14. Ability to introduce a new storefront without modifying existing ones

I'd give commercetools the edge if the retailer has a sophisticated engineering organization and expects the architecture to last 7–10+ years.

I'd give Shopify Plus the edge if reducing implementation/maintenance burden is more valuable than maximum architectural control.

And I'd put BigCommerce in the POC if the business wants a strong multi-store/headless solution but considers full composability more complexity than it needs.

If you tell me roughly how many storefronts, countries, brands, SKUs, annual orders, and whether you have an existing OMS/PIM/ERP, I can give you a much more concrete architecture recommendation—including where I'd put the CMS, search, PIM, API gateway/BFF, checkout, and event bus.

If I were the lead dev making this decision for a large retailer with many storefronts, my default recommendation would be commercetools—unless your organization prioritizes speed-to-market and operational simplicity over architectural control.

My shortlist

Why I'd pick commercetools

For your particular description—large retailer + headless + many storefronts—commercetools maps unusually well to the architecture.

Its platform is API-first/headless and explicitly designed around enterprise-scale commerce. It supports multiple brands/stores and regional operations from a common platform, while allowing the experiences to remain independently developed. commercetools.com

I'd structure it roughly like:

                    ┌──────────────────────┐
                    │   CMS / DAM / PIM    │
                    └──────────┬───────────┘
                               │
       ┌───────────────────────┼───────────────────────┐
       │                       │                       │
 ┌─────▼─────┐           ┌─────▼─────┐           ┌─────▼─────┐
 │ Storefront │           │ Storefront │           │ Storefront │
 │   Brand A  │           │   Brand B  │           │   Brand C  │
 │  Next.js   │           │  Next.js   │           │  Next.js   │
 └─────┬─────┘           └─────┬─────┘           └─────┬─────┘
       │                       │                       │
       └───────────────────────┼───────────────────────┘
                               │
                    ┌──────────▼──────────┐
                    │   Commerce API      │
                    │   commercetools      │
                    └──────────┬──────────┘
                               │
          ┌────────────────────┼────────────────────┐
          │                    │                    │
        ERP                  OMS                  CRM

The important architectural advantage is that storefront boundaries don't have to become commerce-system boundaries. You can give each brand/region its own UX, deployment cadence and content while centralizing the underlying commerce capabilities.

But there's a big caveat

I'd only choose commercetools if you have a genuinely strong engineering organization.

You're buying architectural freedom, not a turnkey ecommerce application. commercetools itself describes the platform as API-first and headless, and its enterprise positioning emphasizes interoperability with ERP, CRM and other systems. commercetools.com

That means your team owns considerably more of:

• frontend architecture
• CMS/PIM integration
• search
• promotions orchestration
• identity
• observability
• integration/event architecture
• deployment infrastructure
• potentially parts of checkout and customer experience

For a large retailer with a mature platform engineering team, that's often a feature. For a team that wants the commerce vendor to solve more of the problem, it's a liability.

When I'd choose Shopify Plus instead

I'd pick Shopify Plus if the primary objective were launching many storefronts quickly with a smaller operational burden.

Shopify's current headless stack gives you the Storefront API plus Hydrogen, while keeping pricing, inventory, carts and much of the operational commerce layer in Shopify. Shopify explicitly supports multiple custom storefronts connected to the same commerce backend. www.shopify.com

So:

commercetools:

"Commerce is a platform capability that we assemble into our architecture."

Shopify Plus:

"Commerce is a managed service that our custom storefronts consume."

That's a pretty important philosophical distinction.

And BigCommerce deserves serious consideration

For a retailer with lots of brands/regions/storefronts but less appetite for building everything yourself, I'd put BigCommerce near the top of the RFP.

It's particularly interesting because multi-storefront management is a first-class concern rather than something you necessarily have to construct yourself. Current industry comparisons also highlight its combination of multi-storefront capabilities and headless flexibility. contracollective.com

My recommendation

If I were setting the architecture direction today:

1. commercetools — best strategic architecture
Choose this if you're building a long-lived enterprise commerce platform and have the engineering muscle.

2. BigCommerce — best pragmatic alternative
Choose this if multi-storefront is critical but you don't want quite as much platform engineering.

3. Shopify Plus — best velocity/operational simplicity
Choose this if getting dozens of storefronts launched and operated efficiently matters more than maximum backend flexibility.

4. Salesforce Commerce Cloud — choose primarily for Salesforce ecosystem alignment
Particularly compelling if CRM, Marketing Cloud, Service Cloud, etc. are already deeply embedded.

5. Adobe Commerce — only if its unusually deep customization is specifically required.

One architectural point I'd strongly recommend regardless of vendor: don't build "one frontend codebase with 30 themes." Treat storefronts as independently deployable experiences sharing a common commerce/domain layer. Shopify's own enterprise architecture guidance makes a similar case for separate frontends with shared backend services, because it prevents one audience's release cycle from coupling to another's. www.shopify.com

If you tell me roughly GMV, SKU count, number of brands/storefronts, B2C vs B2B, countries, and whether you already run SAP/Salesforce/Adobe, I can give you a much more opinionated architecture recommendation—including commercetools vs BigCommerce vs Shopify Plus, estimated engineering complexity, and what I'd put in the RFP.

If I were the lead dev at a large retailer with many storefronts, my default choice would be commercetools—unless your organization already has a strong Shopify or Salesforce footprint.

My ranking

Why I'd pick commercetools

For a retailer with, say, 20 brands × 15 countries × multiple channels, I would want the commerce platform to behave like a central commerce engine, not like a collection of stores.

commercetools is explicitly API-first/headless and models Stores and Channels as separate commerce contexts. That lets you represent different storefronts, pricing contexts, inventory sources, and customer experiences without turning every storefront into a separate application/platform instance. docs.commercetools.com

I'd structure it roughly like:

                    ┌───────────────┐
                    │  CMS / PIM    │
                    └───────┬───────┘
                            │
              ┌─────────────▼─────────────┐
              │     Commerce API Layer    │
              │       commercetools       │
              └─────────────┬─────────────┘
                            │
       ┌────────────────────┼────────────────────┐
       ▼                    ▼                    ▼
  Brand A Store        Brand B Store        Brand C Store
  US / EU / CA         US / EU / APAC       US / EU
       │                    │                    │
       └───────────────┬────┴────────────────────┘
                       ▼
                Shared services
          ┌────────┬────────┬─────────┐
          │  OMS   │ Search │ Pricing │
          │  PIM   │  CMS   │ Loyalty │
          └────────┴────────┴─────────┘

The important distinction is that headless shouldn't mean "build everything yourself." The platform should own difficult commerce primitives—cart, pricing, promotions, orders, inventory integration, checkout, etc.—while your team owns the differentiated customer experience. Shopify's own 2026 guidance makes essentially this distinction: composable architecture is valuable when it removes a real constraint, but it also increases integration and operational burden. www.shopify.com

When I would choose something else

Choose BigCommerce if your primary requirement is many independently branded storefronts with centralized administration, but you don't want to staff a large composable-commerce engineering organization. Its current platform explicitly supports multi-storefront configurations with distinct look/feel/pricing and provides GraphQL plus Catalyst/Next.js for headless builds. docs.bigcommerce.com

Choose Shopify Plus if the organization values speed, ecosystem, and operational simplicity over maximum architectural freedom. Shopify's Storefront API supports multiple custom frontends against the commerce backend, and Hydrogen provides a relatively opinionated headless path. www.shopify.com

Choose Salesforce Commerce Cloud if Salesforce CRM/Marketing/Service is already the strategic center of gravity and the integration benefits outweigh the additional platform complexity.

The bigger architectural decision

As lead dev, I'd actually avoid making the decision simply "which headless platform?"

I'd make the decision:

What should be centralized, and what should be independently deployable?

For a large retailer, I'd generally centralize:

• Product/catalog master data
• Pricing and promotions
• Cart/checkout
• Orders
• Customer identity
• Inventory/availability integration
• Tax/payment orchestration

And make these independently replaceable:

• Storefront frontend
• CMS
• Search
• Recommendations
• Personalization
• Reviews
• Loyalty
• Content/experience orchestration

That gives you a composable commerce architecture without turning the company into a distributed-systems research project.

Bottom line: if you're genuinely a large retailer with a capable engineering organization and expect lots of brands, countries, channels, and differentiated experiences, I'd shortlist commercetools first, BigCommerce second, Shopify Plus third. The more your requirements look like "20 largely independent storefronts sharing a commerce core," the more strongly I'd lean commercetools. docs.commercetools.com

If I were the lead developer at a large retailer with many storefronts, my default recommendation would be commercetools—unless your primary goal is minimizing engineering/operational complexity, in which case Shopify Plus deserves serious consideration.

My shortlist

Why I'd pick commercetools

For your particular architecture—many storefronts rather than just one headless site—I'd optimize for having a single commerce capability layer underneath a large number of independently deployable experiences.

commercetools is particularly strong here because it's genuinely API-first and composable, rather than simply putting a custom frontend in front of a conventional commerce application. Its platform is designed around exposing commerce capabilities to different channels, and the vendor currently positions Sphere for B2C, B2B, B2B2C and D2C use cases from a unified platform. commercetools.com

I'd architect roughly like this:

                    ┌── Storefront A / Brand A
                    ├── Storefront B / Brand B
                    ├── Storefront C / Brand C
                    ├── Mobile App
                    ├── Marketplace
                    ├── In-store / Kiosk
                    └── Future channels
                              │
                         BFF / API
                              │
                 ┌────────────┴────────────┐
                 │      commercetools      │
                 │                         │
                 │ Catalog / Pricing       │
                 │ Cart / Checkout         │
                 │ Promotions              │
                 │ Orders                  │
                 │ Customers               │
                 └────────────┬────────────┘
                              │
       ┌──────────────┬───────┼────────┬──────────────┐
       ↓              ↓       ↓        ↓              ↓
      PIM            OMS     ERP      Search         CMS

The important architectural distinction is that headless ≠ composable. Headless decouples presentation from commerce; composable goes further by allowing commerce capabilities themselves to be assembled independently. commercetools.com

That distinction becomes valuable when you have, say, 20 brands × 10 countries × web/mobile/in-store channels and don't want every storefront team coupled to one giant commerce application.

But I'd seriously consider Shopify Plus if...

Your business is more like:

• lots of storefronts/brands
• conventional retail commerce requirements
• strong need for operational simplicity
• relatively standard checkout/order workflows
• smaller platform engineering organization
• desire to launch new storefronts quickly

Shopify Plus now supports custom/headless storefronts through its API layer and explicitly supports multiple online stores; its current Plus offering says stores can be unlimited, with expansion-store economics depending on the contract. www.shopify.com

That makes Shopify an interesting "buy the commodity, build the differentiation" strategy. I'd let Shopify own the transactional core and put your engineering effort into the experience, orchestration, integrations, personalization, and differentiated retail capabilities. Shopify itself describes this selective-composability model as one of the strengths of its platform. www.shopify.com

The decision I'd make

Choose commercetools if:

• commerce is becoming a strategic technology platform
• you have a substantial platform engineering team
• different brands/regions have materially different commerce rules
• you need freedom to change CMS/search/PIM/OMS/etc.
• you're expecting lots of non-web channels
• avoiding vendor lock-in is strategically important

Choose Shopify Plus if:

• you want the fastest route to reliable enterprise commerce
• most storefronts share conventional commerce behavior
• your differentiation is primarily frontend/customer experience
• you don't want your engineering organization operating commerce infrastructure
• reducing TCO and operational complexity matters more than maximum architectural freedom

The big trap I'd avoid is choosing composable simply because you're a large retailer. Composable architecture buys tremendous flexibility, but it also buys integration work, platform ownership, observability requirements, governance, and more things your team has to operate. Even Shopify's own current guidance makes essentially this point. www.shopify.com

My ranking for your stated scenario:
1. commercetools → best architectural fit
2. Shopify Plus → best operational/TCO fit
3. Adobe Commerce → compelling if Adobe/legacy ecosystem drives the decision
4. Salesforce Commerce Cloud → compelling if Salesforce is your enterprise backbone
5. VTEX → worth evaluating for sophisticated omnichannel retail

If you tell me roughly number of storefronts/brands, countries, annual orders, B2C vs B2B, existing ERP/PIM/OMS, and size of your engineering team, I can narrow this to a concrete target architecture and a commercetools vs Shopify Plus decision matrix.

For a large retailer with many storefronts, I would not choose based on “best headless platform” alone. I’d choose based on the operating model you want: how many brands, regions, channels, catalogs, teams, and integrations you need to support.

For a true enterprise multi-storefront architecture, my shortlist would be:

vendure.io

My default recommendation for a large retailer

I would probably build around:

commercetools + Next.js storefront layer + headless CMS + dedicated search + event-driven integration layer

Example architecture:

                    CDN / Edge
                        |
              Next.js Storefronts
        /          |          |          \
   Brand A     Brand B    Mobile App   In-store
        \          |          |          /
              Experience APIs
                    |
            Commerce Platform
              (commercetools)
                    |
    ---------------------------------
    |       |        |       |       |
 Catalog  Cart   Pricing  Orders  Inventory
    |
 ERP / OMS / PIM / CRM / Loyalty

Why:

• One commerce core, many experiences
• Each storefront can have its own UX, branding, and release cadence
• Shared customer, inventory, pricing, promotions, and order models
• Easier expansion into mobile, marketplaces, kiosks, and future channels
• Less coupling between frontend teams and commerce backend teams

A composable architecture is not automatically better; it increases operational responsibility. The biggest failures I see are not platform failures—they are teams creating five different versions of product, customer, pricing, and inventory data. A successful composable stack needs strong ownership of shared data models and APIs. www.shopify.com

When I would pick Shopify instead

For a retailer with:

• 10–50 storefronts
• mostly B2C
• rapid seasonal launches
• strong merchandising teams
• less need for deeply customized pricing/order workflows

…I would seriously consider Shopify Plus + Storefront API.

You get:

• excellent checkout
• mature operational tooling
• faster store launches
• less platform engineering burden

The tradeoff is that you accept more platform constraints than with a true composable engine. Shopify has increasingly supported headless architectures through APIs and its Hydrogen/Oxygen stack, making it a viable enterprise option. www.shopify.com

Architecture decisions I would insist on regardless of platform

For many storefronts, I would avoid putting everything into the commerce platform. I would separate:

Commerce engine

• products
• carts
• checkout
• orders
• pricing rules

PIM

• product information
• attributes
• localization

CMS

• editorial content
• landing pages
• campaigns

Search

• merchandising
• autocomplete
• ranking

Customer platform

• identity
• loyalty
• personalization

Integration layer

• ERP
• OMS
• warehouse
• tax
• payments

My ranking for a “large retailer lead developer” scenario

1. commercetools — if you truly want a multi-brand, multi-region commerce platform for the next decade
2. Shopify Plus headless — if speed and operational simplicity matter more than maximum flexibility
3. Adobe Commerce — if you have complex enterprise commerce needs and Adobe investment
4. Salesforce Commerce Cloud — if Salesforce is already your enterprise backbone
5. SAP Commerce Cloud — if SAP drives your architecture

The key question I would ask before selecting: How many storefronts, brands, countries, catalogs, and fulfillment models do you expect in 5 years? A retailer with 5 storefronts and one catalog should not build the same architecture as one with 200 storefronts across 40 countries.

For a large retailer with many storefronts, I’d shortlist commercetools, BigCommerce, and Shopify Plus—but my default recommendation would be commercetools if your organization genuinely has enterprise-scale engineering capabilities.

My ranking

1. commercetools — my pick for a true enterprise platform

commercetools is particularly compelling if you're building a shared commerce platform underneath dozens of brands, countries, channels, or customer experiences.

Its API-first/headless model lets you treat commerce capabilities—catalog, pricing, carts, orders, etc.—as services rather than tying your architecture to a particular storefront. commercetools currently positions its platform for very high-scale enterprise workloads, including claims of 100k orders/minute and sub-60ms average response times. commercetools.com

I'd choose it when you have:

• Many brands/business units
• Complex pricing and promotions
• Multiple countries/currencies
• B2C + B2B
• Significant ERP/PIM/OMS integration
• Native apps, kiosks, marketplaces, etc.
• A strong internal platform engineering team
• A desire to avoid rebuilding the commerce layer when the frontend architecture changes

The downside is important: you are buying architectural freedom, not simplicity. Your team owns substantially more integration, orchestration, observability, and platform engineering.

2. BigCommerce — probably the smartest practical choice

BigCommerce deserves serious consideration for your particular requirement.

Its Multi-Storefront capability is explicitly designed for multiple brands, regions, and customer segments while maintaining one backend. It supports distinct domains, currencies, catalogs/categories, customer groups and pricing, while centralizing management. www.bigcommerce.com

More importantly for a lead developer, BigCommerce gives you a relatively clean middle ground:

Commerce SaaS → APIs → your storefront platform

Its headless stack supports REST/GraphQL APIs and modern frameworks such as Next.js, while Catalyst provides a Next.js/React reference architecture. www.bigcommerce.com

I'd lean BigCommerce over commercetools if the goal is:

"We want many independently branded storefronts, but we don't want to build an entire commerce platform ourselves."

3. Shopify Plus — strongest if business velocity matters most

Shopify Plus is excellent if your organization values operational simplicity, ecosystem maturity, and speed of execution over maximum architectural control.

Shopify Plus supports expansion stores under a centralized organization, and its headless stack supports up to 25 custom React-based storefronts using Hydrogen/Oxygen under the Plus plan. help.shopify.com

The architectural caveat is that Shopify's model tends to work best when your stores can operate as relatively independent commerce domains. Shopify itself notes that expansion stores have their own separate data, settings, and configurations despite centralized organization management. help.shopify.com

So if you have 30 brands that mostly behave like separate businesses, Shopify Plus can be fantastic.

If you have 30 storefronts that you want to behave like a single enterprise commerce platform, I'd look harder at commercetools.

What I'd build

For a retailer of significant scale, I'd avoid making the commerce vendor the center of the entire architecture.

I'd structure it roughly like:

                    ┌─────────────────────┐
                    │   Storefronts       │
                    │                     │
                    │ Brand A   Brand B   │
                    │ Brand C   Region EU  │
                    │ Mobile    Kiosks     │
                    └──────────┬──────────┘
                               │
                         Experience API
                               │
              ┌────────────────┴────────────────┐
              │                                 │
        ┌─────▼─────┐                     ┌─────▼─────┐
        │ Commerce  │                     │   CMS/DXP │
        │ Platform  │                     │           │
        └─────┬─────┘                     └───────────┘
              │
       ┌──────┼────────┬──────────┐
       ▼      ▼        ▼          ▼
      PIM    OMS      ERP       Search
       │      │        │          │
       └──────┴────────┴──────────┘

The key architectural decision I'd make is to establish a canonical internal domain/API layer rather than letting every storefront talk directly to 15 backend systems.

That gives you:

Storefront independence → platform independence → controlled integration → centralized observability.

My actual decision

If I were signing off the architecture today:

commercetools — if we're talking about a Fortune-100-ish retailer with a mature engineering organization and genuinely complex multi-brand/multi-market requirements.

BigCommerce — if we want 80% of that architectural flexibility with substantially less platform engineering.

Shopify Plus — if the priority is getting many high-quality storefronts operational quickly and the commerce model isn't unusually complex.

The most important question isn't actually "which platform is best?" It's how many storefronts, brands, countries, catalogs, pricing models, and fulfillment models you need to support—and whether those storefronts share a commerce domain or merely share a corporate parent.

If you give me those numbers (e.g. 20 brands / 12 countries / 5M SKUs / B2C+B2B / existing SAP / existing PIM), I can give you a much more concrete platform + reference architecture + buy-vs-build recommendation.