Bundles and configurators: when you need custom code
Fixed bundles, mix-and-match, and configurable products: what native features and apps handle, and where custom logic is unavoidable.
The short answer
There are three levels of “buy several things as one”, and they need three levels of tooling. Fixed bundles, a set of existing products sold together at one price, are covered by native features with stock tracked per component. Mix-and-match within rules, choose three from this collection, is where bundle apps help. Configurators, where the customer’s sequence of choices changes the price, the available options and the resulting product, need custom logic: a front-end configurator for the experience and pricing rules the checkout enforces. Whatever the browser shows, the price must be calculated from rules the store controls, or the configurator becomes a way to buy things at the wrong price. And stock, fulfilment and returns for bundled and configured products must be designed rather than assumed.
The three levels
| Level | Example | Tooling | Watch out for |
|---|---|---|---|
| Fixed bundle | A starter kit of four products | Native bundles | Stock per component; returns of part of a bundle |
| Mix-and-match | Choose any three from a collection at a set price | Bundle app or native where supported | Rules enforced at checkout; discounts stacking |
| Configurator | A product built from dependent choices with live pricing | Custom front end plus server-side or checkout-function pricing | Price integrity; the resulting item the warehouse can build; lead times |
Designing a configurator
- Write the rules with the product experts: every option, dependency, exclusion, price effect and lead time, as a table.
- Design the experience as a guided sequence with live price and a visual of the result, on a phone.
- Put the pricing rules where the browser cannot change them: server-side or in checkout functions, applied when the line item is created.
- Produce a line item the business can act on: a clear description of the configuration for the customer and a specification for the warehouse.
- Decide stock and fulfilment: made to order, components decremented, lead time shown.
- Decide returns: what is returnable for a configured product, stated before purchase.
- Test every rule path and every attempt to submit an invalid or underpriced configuration.
Bundles and the back office
A bundle sold is several products picked; a configured product sold is a specification for someone to build. Stock must reflect the components; the order must tell the warehouse what to do; returns must have a rule for partial bundles and for configured items; accounting must see the right revenue split. These are designed in the same project as the front end, or they are discovered by operations after launch.
What this means for you
Use native bundles for fixed sets, an app for mix-and-match within rules, and custom logic for configurators with dependent options and live pricing. Never let the browser decide the price. Design stock, fulfilment and returns for bundled and configured products before launch. The right level of tooling for the right level of complexity keeps the experience good and the margin intact.
Frequently asked questions
Can we sell a bundle without an app?
Fixed bundles of existing products, yes, with the platform's native bundle support on plans that include it, tracking stock per component. Mix-and-match within rules is where bundle apps help. Anything where the customer's choices change the price beyond simple sums, or where options depend on each other, is a configurator and needs custom logic.
Why does a configurator need custom code?
Because the price and the resulting product depend on a chain of decisions: this material excludes that finish, this size changes the price of that option, this combination needs a lead time. Apps handle simple option lists; dependency rules, live pricing and a resulting line item the warehouse can build require logic written for your products, in the front end for the experience and in the checkout for the price.
How do we stop someone manipulating the price in the browser?
By never trusting the browser's price. The configurator sends the choices; the price is calculated by rules on the server or through the platform's checkout functions, and the line item is created with that price. If the front end's price is what gets charged, someone will change it. This is the one non-negotiable in configurator design.
Sources
- Shopify Help Center: Bundles (accessed 2026-09-12)