Every store that sells kits and gift sets eventually finds the same nasty gap in the numbers. You put together a starter bundle out of three products you already stock, it starts selling, and a week later the counts make no sense. The bundle says twelve left. The candle inside it says forty left, unchanged since the day you added the bundle, even though the bundle has shipped thirty times. Somewhere a customer just bought the last real candle as part of a gift set, and your store cheerfully sold two more of it on its own product page, because as far as Shopify is concerned those are different things that have nothing to do with each other.

This is one of the most-repeated complaints in the Shopify community, and the threads all describe the same thing in slightly different words. "Bundle inventory not updating." "How do I sell a bundle of two products and make the inventory go down." "My bundle shows sold out but the items are in stock." "Components not deducting when the bundle sells." Merchants are not asking for anything exotic. They want the obvious thing: when a bundle sells, take the parts off the shelf, and when a part runs low, stop promising bundles you can no longer build. Shopify does not do that on its own, and the answers under the threads are always the same short list: track components by hand, or install an app.

What Shopify actually does, and where it stops

Give Shopify its due first, because the picture is better than it was a year ago. The free Shopify Bundles app does link a fixed bundle to its components: you build the bundle from existing products, and it shows the bundle as available based on the lowest-stock component, so it will not let you sell a kit whose parts are gone. For a store that builds every bundle through that app and keeps them simple, that linkage is real and does the core job, and it is a lot more than the platform offered before.

The trouble is how narrow that happy path is, and how many stores fall off it. The native app caps a fixed bundle at a limited number of components and variants, so a big mix-and-match builder outgrows it. It does not track true mix-and-match bundles the same clean way, so the "build your own six-pack from any of these twenty" offer, the one that most needs component math, is exactly the one it handles worst. It tracks a bundle against overall component stock rather than per location, so a store shipping from two warehouses can sell a bundle in a place that cannot actually assemble it. And most quietly of all, it does nothing for the enormous number of bundles merchants built the older way, as a standalone product or a single variant with its own inventory number, which is still how a lot of "buy the set and save" listings exist. Those carry a stock count that no sale of a component ever touches, and no bundle sale ever pushes back down to the parts.

Then there are the seams that break even a linked bundle. Edit an order after it is placed, remove a bundle, add one, change a quantity, and the component math does not re-run, because Shopify never modeled the relationship as something an edit should recalculate. Sync your catalog to another sales channel or a marketplace and the bundle usually travels as one atomic SKU, so selling ten kits on your store leaves the component still showing its full quantity on Amazon, and you oversell the part on the channel you were not even watching. The link that exists is real, but it is thin, and it snaps at exactly the moments a growing catalog leans on it hardest.

A bundle is not a product. It is a promise about several products, and Shopify keeps counting it as if it were one.

Why doing it by hand never keeps up

In theory you can hold this together yourself. You watch the bundles, and when one sells you go and knock the right quantity off each component, and when a component restocks you go and top up every bundle that depends on it. In practice it collapses the instant a component is shared. One candle sits in a starter kit, a deluxe set, a seasonal gift box, and its own product page. Sell one of anything on that list and the real candle count should drop by one, and every one of those four listings should recompute how many it can still offer. Do that arithmetic by hand, across a catalog where things sell all day, and you are always one sale behind, which on inventory means you are always either overselling something you cannot ship or hiding something you could.

Then the judgement creeps in, the way it always does. A component at zero inside a bundle is not the same as one you have chosen to backorder. A returned gift set may have come back with two of its three items, so adding a whole bundle's worth of stock back is wrong. A bundle that dips to zero because one cheap filler part ran out should maybe flip to a short backorder rather than vanish from the store during a promotion. A component you sell both on its own and inside kits may need a reserve held back so the bundles you have already promised can still be built. None of this is a single subtract or add. It is a running recalculation with exceptions, which is precisely what a person loses track of and a rigid rule gets wrong.

What the automation actually has to do

The real job is not "subtract the parts when a bundle sells." It is "hold one honest count for every real component, and treat every bundle as a live recipe drawn from those counts, so any sale that consumes a part updates the part and every bundle and page that shares it, in real time, per location, across every channel, with the odd cases handed to a person." That is a source of truth, a cascade, and a reconciliation that has to run in both directions. As a Dugong playbook, in plain prose, it reads like this: 

# trigger
On any sale, return, restock, or order edit that
   touches a bundle or one of its components

# steps
1. Resolve the bundle to its recipe: which components
   and how many of each, including hidden parts
2. Deduct each component's real stock, per location,
   by what the sale actually consumed
3. Recompute every bundle's availability from the
   parts it needs (lowest full set it can build)
4. Cascade a shared component to every bundle and
   product page that depends on it
5. Sync the corrected counts to the other channels so
   nothing shows phantom stock
6. Hold for review a negative component, a partial
   return, or a bundle better sent to backorder

Six lines. The compiler fills in the rest: reading a bundle as a recipe rather than a standalone number, keeping the component as the single source of truth, doing the math per location so a sale in one place cannot promise a kit another place cannot assemble, cascading one deduction out to every listing that leans on the same part, pushing the corrected figure to every channel so a marketplace stops showing stock the bundle just used, and running the whole thing backward on a restock or a return. The merchant never opened a spreadsheet of SKUs. They described how a careful inventory manager thinks about a kit, and let the compiler run it at the speed orders actually arrive.

◆ NOTE The trap here is treating the bundle as the thing to count. Count the components, and the bundle becomes a view, how many complete sets the parts can build right now, which is always correct by construction. Count the bundle as its own number and you are signing up to reconcile two ledgers that drift apart with every sale: the parts say one thing, the kit says another, and the customer or the warehouse finds the gap before you do. Whether a shared component needs a reserve held for already-promised bundles, whether a part-return should credit stock, and whether a zeroed bundle should hide or backorder are the judgement calls that matter as much as the subtraction itself.

Why this is a compiler problem, not an app problem

There are capable bundle and inventory-sync apps on the Shopify App Store, and a store that oversells its components every week should evaluate one. But the thing that makes this safe is not one more field mapping a bundle to its parts. It is judgement about a specific component at a specific moment: is this bundle out because a real part is gone or because a cheap filler dipped, should a returned kit credit one item or three, does this shared component need a reserve so the kits you already sold can still ship, and which channel is about to oversell the part you just consumed. Those answers change per component, per location, and per order, which is exactly what a fixed rulebook handles badly and a person cannot hold across a catalog that moves all day.

A natural-language compiler fits because keeping bundle and component stock honest was never a single action. It is a source of truth, a cascade across every listing that shares a part, a sync to every channel, and a reconciliation that runs both ways as stock moves. You can describe the whole behavior in a paragraph. You could never keep up with it by hand. It sits in the same family as the overselling problem no one automates, where the same live inventory signal has to drive what the store does next, and the sold-out variant Shopify still shows, where the storefront has to stay honest as stock moves rather than freeze on a stale number.

Picture a holiday season. You build three gift sets, each sharing a hero candle you also sell on its own, and you push traffic at all four. On the current setup, the candle's product page keeps its number all season while the sets quietly empty the real shelf, so you oversell the candle, cannot fulfil two gift sets, and spend the week apologizing and refunding at the worst possible moment. With the automation running, every sale of any of the four drops the one real candle count, all four listings recompute what they can still offer, the marketplace count moves with them, and when your restock lands the sets come back on their own. Same catalog, none of the overselling, and no reconciliation spreadsheet at the end of the month.

The workflow worth building this week

If you sell kits, gift sets, or mix-and-match packs, and especially if a component lives in more than one of them or on its own page, this is the automation to set up now, because the cost is invisible until a customer or a warehouse finds it, and by then you are refunding an order you already promised. It pairs naturally with the inventory work we have written about, like the reorder you always make too late, which keeps the components from going out in the first place, and the restock alert that never fires, which turns the demand on a sold-out kit into a waitlist you own. It feeds the same flywheel as the Shopify automations no one builds, where the work that compounds is the part merchants never get to.

Describe it the way you would brief a careful inventory manager: treat every component as the real count, treat every bundle as a recipe drawn from those parts, and whenever anything sells, returns, restocks, or gets edited, update the parts and recompute every bundle and page that shares them, per location and across every channel, and bring me the odd ones. That is the whole brief. The compiler does the resolving, the deducting, the cascade, and the sync. Your components stop overselling, your bundles stop hiding while their parts sit in stock, and the two counts finally tell the same story.

◆ READING If this resonates, two companion pieces: our dispatch on the overselling problem no one automates, where the live stock signal has to drive every channel at once, and the reorder you always make too late, where the same component count tells you when to buy before you hit zero.

If you are a Shopify merchant who has built something that keeps bundle and component stock in sync and reliably survives returns and order edits, or you have a story about the gift set you oversold through a shared part, the inbox is open: field-notes@dugong.live. We are collecting case studies for the next issue.