Separate storefronts or one platform on a shared backend

B2C and B2B share more than most teams expect, and they diverge mainly in one place. The catalog, the inventory, the customer records, and the order history can serve both audiences from the same foundation. What changes between them is the ordering experience: how prices are set, how an order is placed and approved, how it is paid for, and how it is delivered.

Those four areas — pricing, ordering, payment, and fulfillment — are where the divergence lives. A consumer pays a list price; a business pays a negotiated or tiered one. A consumer checks out a cart; a business may raise a purchase order through an approval chain. A consumer pays by card at checkout; a business often pays on net terms after delivery. A consumer ships to one address; a business may need palletized, scheduled, or split delivery to specific docks.

How to model each of those on a single platform — chain hierarchies, negotiated pricing as a first-class entity, invoice-based order lifecycles — is its own subject, covered in our piece on building a hybrid B2B and B2C platform. The question here sits one level up: the catalog and inventory rarely force a topology decision; the ordering experience does.

The deciding question is how structurally different the ordering experience needs to be, because that is what a frontend either absorbs cleanly or fights. When B2B differs from B2C only by price list and a few role-gated features, one storefront with role-based logic handles it well: the same checkout, the same flows, with prices and permissions resolved per customer. Most of the platform stays single-purpose, and the B2B-specific parts are additions rather than forks.

The picture changes when the B2B ordering experience diverges structurally. These are the signals that one storefront will start fighting itself:

• approval chains, where an order is drafted, reviewed, and approved before it is placed
• purchase-order workflows and PO numbers carried through to invoicing
• recurring or scheduled orders that consumers never make
• bulk ordering, including CSV or spreadsheet imports
• custom delivery terms — scheduled windows, split shipments, dock instructions

When several of these are in play, a single frontend ends up branching most of its screens by buyer type, and every new feature has to be designed twice inside one codebase. That is the point where separate storefronts on a shared backend usually become the cheaper path.

Two topologies are viable, and each trades upfront cost against long-term flexibility.

Single storefront, role-based logic

One storefront serving both audiences is the faster, cheaper start. It launches sooner, reuses the existing B2C investment, and keeps one frontend to maintain. The cost shows up later: every UI and flow decision now serves two audiences, and as their needs diverge the frontend accumulates conditionals — this block for businesses, that one for consumers — until small changes carry risk for both. It stays the right call as long as the ordering experiences stay close.

Separate storefronts on a shared backend

Separate storefronts cost more upfront and pay off when the experiences diverge. Each channel owns its own frontend and ordering flow, so the B2B storefront can carry approval chains and PO workflows without the consumer storefront ever knowing. Underneath, both read from the same backend, so catalog, inventory, and customers stay unified. This is the backend-for-frontend pattern applied to commerce: a tailored frontend-facing layer per interface, sitting over shared backend services.

The trade-offs side by side:

If you are weighing one storefront against separate ones and need to present both with honest trade-offs, that is easier with people who have built multi-channel commerce on a shared backend. Our e-commerce engineering team can map your ordering-experience divergence to a topology before you commit to a build.

Whichever topology you pick, the same things belong in the shared backend, because both channels depend on them being consistent. The product catalog, inventory counts, customer master data, and order history live here, usually alongside a pricing-and-availability service that resolves the right price and stock for a given channel and customer. Unifying these is what gives you consistent stock across channels, cross-channel order visibility, and one source of truth for who a customer is.

Most multi-channel e-commerce platforms share these backend concerns regardless of how many storefronts sit on top. Kortreistved’s dual-channel build is a concrete example: a client webshop and a chain-customers webshop run over one backend, with catalog, inventory, and suppliers shared underneath while each surface owns its ordering flow.

separate-storefronts-shared-backend

Separate storefronts can support different B2C and B2B ordering experiences while catalog, inventory, customer, order, and pricing services stay shared.

The API contract between the storefronts and the backend

The shared backend is only as useful as the contract it exposes to the storefronts. That contract has to guarantee a few things:

• consistent inventory, so two channels never oversell the same stock
• price resolution per channel and per customer, so each storefront shows and charges the right price
• order creation with channel attribution, so every order records where it came from
• shared customer identity, so a buyer is recognised across storefronts

Composable commerce platforms make this concrete. In Medusa, a storefront request carries a publishable key scoped to a sales channel, which returns the right products and inventory and attributes the order to that channel; commercetools models the same idea through Stores and Channels over one API-first backend.

Aggregating requests so the storefront stays simple

A single storefront action — rendering a product page, placing an order — often needs data from several backend services at once. Rather than have each storefront orchestrate those calls, an aggregation layer combines them behind one request, which is the gateway aggregation pattern. It keeps the frontends thin and the chattiness between storefront and backend under control, which matters more as the number of storefronts grows.

SaaS platforms support B2B natively, within their storefront model. Shopify, for example, models B2B with company accounts: companies and company locations, company-specific catalogs and price lists, approval-style draft orders, and payment terms. For a B2B channel whose ordering experience stays close to the consumer flow, this is fast to adopt and avoids building anything custom.

The cap is the frontend. The B2B experience lives inside the platform’s storefront and theming, so a genuinely distinct B2B ordering UX pushes against what the platform is built to do. At that point teams either accept the platform’s constraints or move to a composable backend where separate storefronts can each own their experience. The choice maps back to the same question — how different the ordering experience needs to be.

Sometimes the right answer is to build neither yet. When the B2B channel is small — a handful of wholesale accounts — a manual process can be cheaper than any architecture: orders by spreadsheet, invoicing by email, fulfillment handled by hand. Building a storefront or a shared-backend integration only pays off once the volume or the operational pain justifies it. Once it does, vetting a build partner matters as much as the topology, and the e-commerce RFP technical questions to put to a vendor — code ownership, handover, production risk, and proof-of-concept scope — are worth settling before any contract.

The other case is divergence in the data itself. If the product catalog for B2B and B2C diverges so far that they share almost no products, attributes, or structure, putting both on one shared catalog can create more friction than it removes, and you may be looking at two systems rather than one backend with two faces. Knowing when you have crossed that line — and the related question of when to move from a plugin to a purpose-built platform — is worth settling before committing budget.

• Catalog, inventory, customer master, and order history belong in one shared backend regardless of whether B2B and B2C share a frontend.
• The choice between one storefront and separate storefronts turns on how structurally different the ordering experience needs to be, not on the catalog or inventory.
• A single storefront with role-based logic ships faster but accumulates conditionals as the audiences diverge; separate storefronts cost more upfront and isolate each channel’s UX.
• The shared backend’s value depends on a clear API contract: consistent inventory, per-channel and per-customer pricing, order attribution, and shared identity.
• Sometimes neither build is justified — a manual process can be cheaper for a small B2B channel, and a fully divergent catalog may not belong on a shared backend at all.

The architecture follows one question rather than the other way around. Put the catalog, inventory, customers, and orders in a shared backend, then let the degree of divergence in the ordering experience decide whether one storefront with role-based logic is enough or whether each channel needs its own frontend.

Design the API contract between storefronts and backend deliberately, because that is what keeps stock, pricing, and identity consistent across channels. And when the B2B channel is small or the catalogs barely overlap, the cheapest architecture may be none at all for now.

If you are scoping a B2B channel onto an existing B2C platform and want a clear read on which topology fits, a short conversation will get you there faster than another month of patching. Talk through your channel architecture.