Product bundles: inventory, pricing and the four ways to build them

Before comparing implementations, answer two questions in plain language. Almost every bundle problem we get called about is one of these two being answered differently by the storefront and the warehouse.

Does the bundle exist physically? If somebody picks three items, puts them in one box and puts a barcode on it, the bundle is a product with its own stock and its own SKU, and the interesting work is in production planning, not on Shopify. If the bundle only exists as an idea — three things that ship in three cartons, priced together — then it has no stock of its own and must never be given a number that looks like stock.

Where does the price live? A fixed bundle sold at £120 when its parts total £145 has a price on the parent product. A "buy any three, save 20%" offer has no price at all, only a rule. The difference matters more than it sounds, because a price that lives on a parent product is a number a human maintains, and a rule is a number that recalculates itself. The most common bundle failure in year two is not a bug — it is a bundle still priced against last year's component costs.

Everything after this follows from those two answers.

Roughly in order of cost, cheapest first. The right one is usually further up the list than the one being proposed.

1. A discount, not a bundle. "Buy the shirt and the tie, get 15% off" is an automatic discount. There is no bundle product, no parent SKU, no new inventory concept, and nothing to keep in step when a component changes. The buyer adds ordinary products; the cart does the arithmetic. It is also the only one of the four that degrades gracefully: if a component sells out, the offer simply does not trigger, and no page on your site is advertising a thing you cannot ship.

What you give up is merchandising. A discount is not a product, so it has no page, no photograph of the set, no place in a collection, and nothing for search to index. If the bundle is a marketing asset — a gift set, a starter kit — that absence is the whole problem, and you need one of the next two.

2. A fixed bundle with derived inventory. This is Shopify's own model: the bundle is a product, its price is set on the parent, and its available stock is calculated from the components. That single sentence is the entire reason to prefer it over the homemade version — you cannot oversell a component by selling the bundle, because the bundle's availability is a function of the parts rather than a number somebody typed. You get a real product page, real photography, a collection entry and structured data. It is the default answer for gift sets and multipacks.

3. A cart transform function. When the bundle is composed by the buyer rather than by you — pick any four from this range, build your own box — the composition happens at cart time. Shopify's Cart Transform API gives three operations: expand a single line into its components, merge several lines into one presented line, and update a line's price, title and image. Expansion carries per-unit price adjustments, so a mix-and-match set can be priced correctly at the component level while presenting as one thing. The constraints are documented and worth knowing before scoping: one cart transform function per app per store, up to 2,000 units per expanded or merged item, and line updates limited to Plus and development stores.

4. A physically packed product. The bundle is picked, boxed and stocked as its own unit. Shopify needs to know nothing clever: it is a product with stock. This is the right answer more often than the technically-minded expect, particularly for a bestselling set — it removes every synchronisation problem at once and replaces it with a warehouse task somebody was probably doing anyway. The cost is flexibility: repackaging a slow-selling bundle is a physical job, not an admin change.

Launch is rarely where bundles fail. The failures are all downstream, and the same handful recur.

Subscriptions. Bundles and selling plans do not combine: Shopify documents cart transform operations as rejected at checkout when a selling plan is present. If someone has promised a subscribable bundle box, that promise needs redesigning — usually as a single subscribable product whose contents vary, rather than as a bundle of subscriptions.

Discount stacking. On a fixed bundle, a discount is allocated across components in proportion to their prices, and a product- or collection-specific discount has to target the parent. That is reasonable behaviour, and it is not the behaviour most merchants assume, so a "20% off everything" weekend applied to a range that includes bundles needs testing against an actual order before it runs.

Returns. A bundle bought at a discount and returned in part is an arithmetic question your returns policy probably has not answered. Decide it in advance: partial returns at the allocated line price, or bundle returns only. Both are defensible; discovering it at the counter is not.

Reporting. Because orders carry component SKUs, bundle revenue is not a column you get for free. If bundle performance is going to be judged, agree how it is measured before launch — an order attribute, a line-item property, or a tag — rather than reconstructing it from six months of orders afterwards.

If the bundle is a promotion, use a discount and stop. It costs nothing, breaks nothing and can be switched off in an afternoon. A surprising share of bundle projects we are asked to scope are promotions that acquired a product page somewhere in the planning.

If the bundle is a product a customer would search for, use a fixed bundle with derived inventory, and accept the manual price maintenance as the price of the product page. Put the quarterly price review in someone's calendar on launch day.

If the buyer composes the bundle, you are building a configurator with a cart transform behind it, and the work is mostly in the interface, not the function. Budget accordingly, and check the 3-option, 100-variant ceiling against the range before anyone designs a screen.

And in all three cases, keep stock in one place. Every bundle disaster we have been called in to unpick has the same root: two systems each holding a number they believed was the truth.

• Shopify support and store management
• Inventory truth: the number three systems disagree about
• Discount logic that survives your next promotion