Why a fixed bundle sells more than you can build, and three ways to stop it — two of them free.
A fixed bundle is one product on the storefront that you assemble from several components you also stock on their own. Shopify works out how many of it can be sold from those components: for each one, take its available quantity, divide by the number of units a single bundle needs, round down, and the lowest result is the number of complete bundles. A kit that needs two straps and one buckle, with seven straps and five buckles on hand, can be sold three times — not five, and not seven.
The same documentation names the two exceptions, and they are where oversells come from. A component whose inventory is not tracked, or that is set to continue selling when out of stock, is ignored when the bundle's quantity is calculated. In effect the bundle behaves as though that component were infinite. Shopify's default for every product is to stop selling at zero, so the hole only opens when someone switched the policy on, often for a reason that no longer applies, or never turned tracking on for a part.
The third cause lives outside Shopify's own arithmetic. A kit whose quantity is written by a third-party sync — a bundle app that keeps the parent's stock number itself — can drift from the components it was built from between syncs, so the storefront shows more than can be assembled. None of these holes announce themselves: the bundle looks healthy right up to the order you cannot pack.
Source: Shopify Help Center — eligibility and considerations for product bundles
Open each component product in the admin, go to its variant, and in the Inventory block turn on Track quantity. Then make sure Continue selling when out of stock is off: the default is to stop selling at zero, and that default is the setting you want on every part of a bundle. Enter the real on-hand quantity. Do it for every component in every bundle, because a single untracked or continue-selling component is enough to open the hole for the whole kit, and bundle stock is counted across all locations rather than per location, so a quantity you forgot at a second warehouse still counts.
If the bundle's own variant carries a quantity of its own — the usual case when a kit is pre-packed, or when an app writes the parent's stock — keep that number consistent with the components: never higher than the buildable count from the arithmetic above. When it is higher, the storefront will accept orders the shelf cannot fill.
This is free, needs no app, and fixes the two biggest causes outright. Its limit is that it is a snapshot. Nothing stops the next new product being created with tracking off, nothing warns you when a tracked component is down to its last few units, and when a component does run out the bundle simply vanishes from sale with no message to you. Correct, but a surprise.
A spreadsheet with one row per bundle. For each component, two cells: the quantity one bundle needs, and the quantity available right now from the admin. A third cell divides the second by the first and rounds down. The bundle's buildable count is the minimum of those cells across its components — the same number Shopify computes, but with the untracked and continue-selling exceptions removed, because you are counting every part whether or not Shopify would.
Two things to get right. Count a shared component once: if two kits both use the same strap, both draw on the same pile, so one sheet that lists the strap under each kit independently will overstate both. And compare the result with what the storefront shows for the bundle. When the storefront claims more than the sheet allows, you have found a component with the wrong settings or a sync that has drifted, and method 1 tells you how to close it.
Run it before every campaign and on a fixed day each week, and it works. Its cost is that the available column is stale from the first sale after you typed it, and nobody is warned by a spreadsheet. It tells you what is at risk on the days you remember to open it, and components run out on the other days.
This is what BundleGuard does: the sheet from method 2, read from your live stock instead of copied away from it, and run every day and each time you open the app. For every fixed bundle that exposes its components through Shopify's bundle data it computes the buildable count — for each tracked component, available divided by quantity per bundle, rounded down, lowest wins — and flags each hole by name: a component that is not inventory-tracked, one set to continue selling when out of stock, a tracked component that is out, and a bundle whose own availability is higher than its components support. Kits that Shopify does not know about can be added by hand, with the variant you sell and the components that go into it, and are watched the same way.
With access to your order history it also forecasts. From the last 30 days of orders it measures how fast each bundle and each component sells, adding up every bundle that draws on a shared part, and shows per bundle roughly how many days until it runs out, which component is the bottleneck, and how many units of it to order to cover the next 30 days. Bundles running out within a week are flagged as warnings before anything is actually wrong; the window is adjustable.
Alerts are one email per new issue, with no repeats while it stays broken, plus Slack and a Shopify Flow trigger if you want to build your own workflow, and a Monday summary. Auto-protect is off by default and switched on per bundle: when a protected bundle can no longer be built, the app sets that product to Draft so it leaves the storefront, and sets it back to Active when the components are back. It only ever restores a product it drafted itself and never touches one you set to Draft by hand. That status change is the only write the app makes; it never changes inventory quantities, edits the theme, adds tags, or reads customer names, emails or addresses.
The Free plan covers the three bundles most at risk, with buildable stock and forecasts. Standard is $9.99 per month, or $99.90 per year, with a 14-day free trial, billed through Shopify: every bundle, Auto-protect, email, Slack and Flow alerts, and the weekly summary.
Do method 1 regardless; it costs nothing and it is what the other two depend on. If you have a handful of bundles, components that nothing else shares, and sales slow enough that a weekly check is early enough, method 2 is a real answer and the instructions above are complete on purpose. The app earns its price when bundles share components, when a new product can appear with tracking off without you noticing, or when the cost of one unfulfillable order is higher than the cost of hearing about it a day before it happens.
BundleGuard: Oversell Watch · Shopify App Store listing · How-to guide and FAQ