Field Note

Multi-brand commerce needs rules before platforms

A stream running through a forest
A stream in the woods.

Multi-brand commerce programs love to begin with a platform question. One instance or several? One storefront framework or many? Central control or brand autonomy?

Everyone can argue about that for months. The platform still cannot answer it.

First the company has to decide what the brands are actually allowed to share.

Without those rules, “shared” becomes a negotiation inside every feature and release.

Similar is not the same as shared

Two brands may both need catalog, pricing, promotions, content, checkout, payments, and orders. That does not mean they need the same behavior in each area.

One brand may sell internationally. Another may have a dealer network. One may rely on subscription. Another may have complex bundles, regulated products, or store fulfillment. Their teams may also work at different speeds and use different agencies.

A common capability is only useful if the shared model supports the variation that matters.

Otherwise the company either forces brands into a compromise or fills the platform with conditional behavior until nobody can explain the standard path.

Use three levels of decision

I find it useful to separate capabilities into three groups.

Mandatory shared standards are areas where consistency protects the enterprise: identity, security, payment controls, core data contracts, observability, accessibility expectations, and perhaps a common order or customer model.

Optional shared services earn their keep when they fit: search, content components, experimentation, promotions, tax, fraud, or a storefront foundation.

Brand-owned decisions preserve meaningful differentiation: experience, merchandising, campaign cadence, content voice, and business rules specific to the brand.

The exact boundary will differ. The important part is deciding it intentionally.

Centralization needs a service model

A shared platform team is not automatically a shared service.

Brands need to know what the team owns, how work is prioritized, which capabilities are available, what service level to expect, and how they can extend the platform without breaking the common layer.

If every request enters one enterprise backlog, brand teams will route around it. If every brand can modify the core, the platform will stop being common.

The shared team needs product management, technical ownership, and a funding model. Otherwise centralization is just dependency with a steering committee.

Price duplication against coordination

Separate platforms duplicate licensing, integrations, upgrades, security work, and specialized skills. A single platform concentrates those costs but adds coordination and can increase the blast radius of change.

Neither is free.

The decision should compare the recurring economics:

  • How much implementation is genuinely reusable?
  • How often do brands need to release independently?
  • Which integrations can be shared without creating a bottleneck?
  • How different are the business and regional requirements?
  • Who pays for the common layer and exceptions?
  • What happens when one brand outgrows the model?

The lowest license count is not necessarily the lowest operating cost.

Design an exit from the shared layer

Brands and portfolios change. Acquisitions happen. Divestitures happen. Strategies change.

A multi-brand architecture should make it possible to separate a brand without reconstructing every business rule from shared code and data. That does not require complete isolation. It requires clear ownership, contracts, and data boundaries.

The same design also makes onboarding a new brand more predictable.

If adding or removing a brand is a one-off archaeology project, the platform is shared in ways the organization does not understand.

Start with the operating constitution

Before choosing the instance model, write down which decisions belong to the enterprise, the shared platform, and the brand.

Test those rules against the brands that differ most, not the two that already work the same way.

Then choose the architecture that makes the intended decisions easy and the prohibited ones difficult.

Multi-brand commerce is not a consolidation exercise with different logos. It is a governance model wearing technology.

Get the rules wrong and the platform will spend years losing the argument for you.

Field Notes

More Field Notes.