Guides

Multiple stores, one inventory: the operating model

Two or more Shopify stores can sell the same physical stock without lying to customers, but not by default and not by discipline alone. Here is the architecture that holds up: one source of truth, hub and spoke, and rules a team can actually follow.

Running two Shopify stores on one pool of stock is common. Running five is not rare. What is rare is doing it without the stores quietly disagreeing about what is on the shelf — because Shopify gives every store its own private inventory and no way to share it, so agreement is something you have to construct.

This guide is about the construction: the shape that works, the rules that keep it working, and the places it breaks. If you are still deciding whether to run more than one store, start with whether you need a second store at all — every store you do not open is a sync you never run.

First, check the premise: one pool or several?

“Same inventory” only means something if the stores sell from the same physical stock. One warehouse, several storefronts: that is the mirroring problem this guide covers.

If each store has its own warehouse — a US store shipping from New Jersey, an EU store shipping from Rotterdam — you do not have one pool, you have two, and mirroring one store’s numbers into the other would advertise stock that cannot ship. That situation wants a different architecture, built on transfers rather than sync.

The shape that fails: a mesh

The intuitive setup for three stores is “keep them all in sync with each other” — every store connected to every other, changes flowing in all directions. It fails for a structural reason, not a tooling one: when two stores disagree, a mesh has no answer to which one is right. Every pairwise connection needs a conflict rule, every conflict rule is wrong in some scenario, and the number of connections grows quadratically — three stores is three links, five stores is ten.

The shape that works: hub and spoke

One store owns the number. Every other store follows it. That is the whole architecture:

• The source is wherever physical reality is already recorded — receiving, stocktakes, write-offs, returns to the warehouse. Its count is the count.
• The destinations mirror the source, one way. Nobody edits stock in a destination, because the edit would be a lie with a countdown: the next source change overwrites it.
• Adding a store adds one connection. A fourth storefront is one more spoke, not three more relationships to reason about.

One-way is the load-bearing property. The moment a destination can write back, you are back to needing a conflict rule, and back to the mesh problem with extra steps. The two-store guide covers why this holds even at N=2.

The five rules that keep it true

Architecture survives contact with a team only if the rules are few and blunt. These are the five:

1. All stock edits happen in the source. Receiving, corrections, write-offs, stocktakes. If a destination’s count looks wrong, the fix is a source edit, never a destination edit.
2. Destination refunds do not restock. Shopify’s refund flow offers a restock toggle; in a destination store that toggle writes destination inventory, which the sync will overwrite. When goods physically come back, they come back to the warehouse — record them in the source.
3. Turn off “continue selling when out of stock” in destinations. The mirror can only protect you if zero means stop. A destination that keeps selling at zero has opted out of the whole system, one product at a time.
4. Keep SKUs disciplined. Matching runs on SKU, so duplicate and blank SKUs are a ceiling on how well any of this can work. Audit before connecting, and re-check after catalogue edits.
5. Check for drift on a schedule. A sync that fails does so silently. Comparing every matched SKU across stores — weekly at minimum, daily in season — is the difference between finding a gap and a customer finding it. Overselling is what the gap costs.

The rules have an organisational edge worth stating in the open: destination staff lose the ability to “just fix” a number. That is the point, and it needs saying out loud to the people it affects, or they will fix numbers anyway and be confused when the fixes vanish.

Rolling it out across three or more stores

Do not connect everything at once. The sequence that avoids surprises:

1. Fix the SKU audit findings in the source first — every destination inherits them otherwise.
2. Connect one destination in a preview or dry-run mode. Read the match report: the unmatched list should be exactly the items you expect that store not to carry.
3. Go live on that one store. Watch it for a few days — the drift check should be boring.
4. Repeat per store. Each new spoke is the same procedure against the same source, which is precisely why the hub shape scales and the mesh does not.

What this deliberately does not share

Inventory quantities are the part that must agree. The rest of the catalogue often should not: each store keeps its own prices (a wholesale store depends on that), its own titles and translations, its own collections and merchandising. Products themselves are a separate copying problem with separate tools, and orders stay where they were placed.

That separation is a feature. The stores exist because they serve different audiences; the shelf is the only thing they genuinely have in common.

Where StockUnison sits

StockUnison is the hub-and-spoke model as an app: one main store, one-way sync into as many connected stores as you like, matched by SKU with duplicates refused rather than guessed at. Every connection starts in preview mode, every write is logged, and the difference report is the scheduled check from rule five. Pricing is per live destination — $19/month for one, $39 for five, $79 unlimited — and the free plan runs matching, preview mode and difference checks across an unlimited catalogue, which covers the entire rollout sequence above except the final go-live.

What it does not do: two-way sync, per-store allocation of a shared pool, or copying products and prices. If destinations genuinely need to write back, this is the wrong tool and the honest alternatives are in the comparison.