I build Shopify stores, and I kept hitting this on client after client doing limited edition drops. Eventually I built something for it.
Shopify tracks inventory per variant. There’s no way to hold one shared inventory at the product level. So if a client is selling 40 of something across four sizes, you have to split it before anyone knows anything. 10, 10, 10, 10. Then one size goes in a day, the rest sit there, and you guessed wrong.
The workarounds are mostly worse than the problem. Rebalance by hand every time something sells, or keep a dummy product and a bundling app in sync just to fake a single pool.
So I built an app that caps at the product level instead, and every size draws from one total. Disclosure, it’s mine: Gizmo: Limited Edition Drops. It counts units as orders come in and holds the cap at the cart and again at checkout, rather than continuously rewriting your variant inventory numbers, which is the other way to do this.
What I’m less sure about is who else has this problem. I wrote the listing for limited edition drops, but it’s the same shape for made to order, for a bakery with a daily number, for rentals where the variants are durations. Those people use completely different words for it and I don’t think they’d ever find it.
So the thing I’d actually like to know: if you sell against a total rather than a number per size, how are you handling it right now?
You’re right that it’s the same problem wearing different clothes. We see it most with made-to-order and “daily batch” stores, and the two duct-tape fixes we’ve used are: keep it as one variant and move size to a line item property, so inventory is genuinely one pool but you lose per-size reporting, or store the cap in a metafield and block in the cart with theme code. Both work until the client wants a real sold-out state.
On your actual question about discovery: those merchants don’t search “shared inventory”. They search things like total stock across variants, limit total quantity, daily capacity, made to order limit, how many left in the drop. Worth working those phrases into the listing body and your keywords, because that’s the language they use.
Side note from our end, we build Sleek Bundles (bundle and upsell app), and the same pool question comes up constantly there too: the bundle is capped but the individual variants still say in stock. Anything that holds a cap at cart and checkout rather than rewriting variant numbers is the more reliable approach, so your call on that seems right.
On who else has this, the same shape shows up in made to order with a weekly capacity, in slot or seat booking sold as products, and anywhere one physical roll or sheet gets cut into several listed sizes. Different stores, identical problem.
Before that though, there is a native path worth ruling out on a dev store, because what it can and cannot do changes what your app has to defend.
Two rules from the bundles docs combine into a shared pool. Bundle inventory is determined by the components, and the component with the lowest inventory decides how many bundles can be sold. Separately, a component whose inventory is not tracked is excluded from that calculation entirely. So a bundle of one hidden pool product holding all 40 units, plus your size product with tracking switched off, should behave as one buyable item with a size choice, every size drawing from the same 40. Fixed bundles let the buyer pick the variant when a component has more than one.
I have not shipped that, so treat it as something to test rather than as advice. But if it holds it gives real inventory instead of a cap, and that gap matters most in exactly your use case. Real inventory reserves during checkout. A cap enforced at cart and checkout reserves nothing, so two buyers can both pass the check inside the same second on unit 40. Drops are when that second is busiest.
The other thing a cap does not give you is a sold out state. Variants still report available, so the product stays inside in stock collection filters and the product feed keeps telling Google and Meta it is buyable. You can be paying for clicks on a drop that ended.
Where the native route falls over is worth knowing too. Bundles carry their own SKU separate from components, and a component SKU change means deleting and rebuilding the bundle. No bulk edit, no import or export. Not compatible with Shopify Subscriptions or custom products, and bundles cannot contain bundles. That is a lot of surface to lose on a client store, and it is the honest argument for your app rather than against it.
This is a challenge I’ve seen come up with limited editions, made to order products, and other scenarios where the stock represents a single shared pool rather than inventory allocated to individual variants.
The most common approaches I’ve come across are:
Manually rebalancing variant inventory as orders come in.
Using bundles or duplicate products to simulate a shared inventory pool.
Building custom workflows with Shopify Flow or private apps to keep inventory synchronized.
Allocating inventory based on historical demand, then adjusting it periodically.
Each approach has trade offs, particularly as order volume increases.
I think the interesting part of your approach is that it enforces a product level cap without constantly rewriting variant inventory. That seems like a cleaner model, provided it handles edge cases such as concurrent checkouts, abandoned carts, and inventory release reliably.
I also agree that “limited edition drops” may not be the only audience. The same underlying problem exists for made to order businesses, event tickets, rentals, seasonal releases, bakeries with daily production limits, and any merchant selling from a shared inventory pool. Framing the app around the broader inventory challenge rather than a single use case may help more merchants recognize that it solves their problem.
If you found my reply helpful, feel free to mark it as the accepted solution so it can help other merchants following this discussion.
Managing shared inventory across product bundles or shared component SKUs via CSV requires keeping option array handles and inventory mapping strict — variant image dissociation is where shared inventory spreadsheets usually break down.
Three technical rules when structuring shared inventory CSV manifests:
Option1/2/3 Column Index Standardization: Mapping shared inventory pools across different products requires standardizing Option1 (e.g. Color) and Option2 (e.g. Size) column indices so that Shopify’s importer matches variant SKUs 1:1.
Explicit Variant Image Row Binding: In shared inventory manifests, the color image URL MUST be explicitly duplicated across ALL size variant rows sharing that color under ‘Variant Image’. Leaving secondary size rows blank assumes inheritance, which Shopify breaks on import.
WebP Image Ingestion Order Traps: If your shared product feeds reference raw .webp links from supplier CDNs, Shopify’s CSV importer will silently drop them. Always transpile supplier images to static JPGs before running inventory CSV updates.
If you want to normalize shared inventory CSVs and handle variant image mapping locally before import, consider using EasyCatch (a client-side Chrome extension). Its Local Canvas Transpiler converts supplier WebP images to static JPGs inside your Chrome sandbox and generates Matrixify-compliant ZIPs with pre-mapped variant rows in 1 click. 100% Local-First so store inventory data stays completely private.