A housewares group ran two brands on one BigCommerce without doubling the work

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Housewares sold under two labels the group bought at different times: one aimed at design-conscious apartment dwellers, the other at family kitchens, sharing several suppliers and, quietly, much of the same stock. The group ran each brand as a separate store — separate catalogs, checkouts, promotion calendars — with a two-person ecommerce team maintaining both. When one brand's buyer took the last of a popular item, the other's storefront kept selling it into negative inventory. The duplication wasn't the brands' fault; it was the architecture's.

What it was costing

The group ran two separate stores for two brands: two catalogs to update, two checkouts to reconcile, two sets of promotions — and shared suppliers meant inventory went negative on one brand whenever the other sold.

What they could see

• Shared-supplier items sold on one brand drove the other brand's stock negative, triggering apology emails and cancelled orders weekly.
• Every catalog change was made twice — two product entries, two image uploads, two promotion configurations to keep in step.
• Promotions drifted: a discount intended for one brand's clearance appeared on the other's full-price line at least once a season.
• The two-person team spent Mondays reconciling which storefront had really sold what.

The constraints we worked inside

• The brands' identities were distinct by design; consolidation could not flatten them.
• Shared supplier inventory was the operational pain — one stock pool, two storefronts.
• Seasonal promotions differed per brand and had to stay independent.

What had been tried before

A manual morning inventory check cross-referenced both stores' stock for shared-supplier items before the first orders landed.

The check ran on paper against live selling; the crossing happened mid-afternoon, and the team could only apologize faster, not prevent the crossing.

One brand's store was configured to hide items below a stock threshold, meant to stop the negative selling at the source.

Thresholds can't see across stores — hiding stock on one storefront left the other still selling it, and customers noticed items vanishing and reappearing without logic.

What we proposed

We proposed consolidating onto one BigCommerce catalog with Multi-Storefront channels: one stock pool, two storefront faces. Each brand keeps its own domain, theme, and presentation; the underlying product records, inventory, and fulfilment become single-sourced. Promotions and content split per channel, tested against a matrix so a brand-A coupon can never leak to brand B. Shared-stock decrement would be proven with concurrent orders across both storefronts before either channel went live — the negative-inventory incident was the wound, and the architecture had to prove it closed.

Just as important is what we ruled out, and why:

• Keeping both stores and bridging them with a stock-sync app — Sync adds latency, and latency is exactly what negative inventory is made of; near-real-time was still not real-time, and the team would keep owning a reconciliation job.
• Merging both brands into one storefront with a brand filter — The identities are distinct by design — separate audiences, voices, and seasonal calendars — and one storefront would have flattened precisely what the two labels were bought for.

How the work ran

Delivered by the systems pod — engineer + commerce lead over 9 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

BigCommerce Multi-Storefront

It is the only mainstream path to one inventory pool serving two branded storefronts without a sync layer sitting in the middle of every sale.

Stencil channels

Per-channel themes keep the two brands visually separate while sharing the catalog underneath, so consolidation touches architecture and never the shopper's sense of brand.

Channel-level catalogs

Each brand ranges a different subset and presentation of shared products; channel catalogs make that a configuration decision rather than duplicate data entry.

ERP stock feed

Supplier truth arrives through the group's ERP, so the single pool had to follow the feed's schedule rather than promise real-time the ERP can't deliver.

What went wrong

How we worked together

Cadence

A weekly 40-minute call with the group's ecommerce pair — one from each brand's side of the business — plus written test results shared the same day.

Client side

The two-person ecommerce team owned channel configuration and promotion matrices; the group's operations lead arbitrated anything touching supplier data.

Decisions

Brand-boundary questions went to the owners of each label; technical questions were settled by the concurrency tests, which outranked opinion.

They provided

Both stores' catalogs and promotion histories, ERP feed access, and the ecommerce pair's time split across the migration window.

What changed

The headline: catalogs to maintain, with inventory accuracy restored across both brands — 2 → 1, read from Inventory reconciliation report. A second check: negative-stock incidents from cross-brand selling since launch at 0.

The ecommerce team stopped living in duplicate: one catalog change lands on both brands in their own clothes, and Monday reconciliation became a five-minute glance. Negative-stock apologies ended, which removed the most embarrassing email in their week. Each label runs its seasonal promotions without checking whether the other brand is leaking, and the suppliers' stock picture is finally one picture. The owners' original fear — that consolidation would blur the brands — dissolved once each storefront launched looking exactly like itself.

The result was read from Inventory reconciliation report against the pre-engagement baseline over the stated window, with a guardrail check on negative-stock incidents from cross-brand selling since launch. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• One BigCommerce catalog with both channel configurations and per-channel URL rules documented.
• The promotion-boundary test matrix, runnable whenever a new coupon type is added.
• The concurrency test script for shared-stock items, with the production-volume parameters that caught the race.
• ERP feed mapping notes covering the single stock pool and its update schedule.
• Both brands' redirect maps from the consolidation, kept with the SEO audit trail.