Fixed Bundles and Kit Merchandising on Shopify

Definition

Pre-composed kits and multipacks sold on their own templates: 'what's inside' contents modules, per-component ingredient breakdowns, shade-selectable kit contents, savings badges and bundle-aware cart display. The merchandising layer that makes a kit feel like a product rather than a discount.

The Evidence

• Evidence strength: 23 live, Deploi-attributed builds across 3 Shopify storefronts.
• Split by storefront: Nudestix 12, Three Ships 9, LUS Brands 2.
• Split by attribution: 17 Deploi-authored, 6 modifications of vendor theme code — named as such on each build page.
• Evidence quality: eight carry code plus client working records. Fifteen are documented from the code; no client-side record of the decision survives.
• Confidence: 6 strong, 17 moderate.
• Surfaces: product pages, collection templates, campaign landing pages, the cart.
• Status: Live, verified 2026-09-06. Buy-vs-build verdict: mixed — see below.

How It's Actually Built

Start from the platform fact that shapes everything else: on these storefronts a kit is an ordinary Shopify product. It has its own price, its own inventory and its own reporting, and Shopify has no native notion that its line item is a set. So composition lives in metafields — a product list of components, a list of component titles, a metaobject holding a promotion's rules — and the contents ride to the order as line-item properties. One storefront flattens custom.order_bundle_product_title into a hidden properties[_product_meta] input so the pick-and-pack list appears on the order line; another writes a human-readable line per pick plus _variant_ids and a generated _bundleId, which is what makes an in-cart bundle editable at all.

On top of that sits the merchandising layer, and it is most of the work. A contents module — a scrollable component list beside a hero image — is the single most-deployed custom section in this corpus, running on 38 templates. A rationale section answers why these products together under a fixed #why-kit anchor across 23 bundle templates. A per-component breakdown gives each formula in the kit its own ingredient cards, an AM/PM usage pill and a statistics grid with its footnote. The forked price.liquid reads a product-value metafield and renders the kit's notional retail value beside the price, with a percent-off badge computed inline from compare-at. Cross-sell rails place the kit next to the individual products it collects, so a shopper reading one component's page meets the set it belongs to.

The hardest piece is choice inside a fixed kit. bundle-kits.liquid renders linked kits as an accordion on each component's product page, and bundle-products.liquid renders one card per component with its own shade picker, each option's variant JSON inlined next to its swatch so selection needs no round trip. A "more info" drill-down fetches the real product page through an alternate view and lifts its markup into the modal, so the panel always matches the live PDP rather than a second copy of it. One add-to-cart at the end, posting the kit's own variant.

The Buy-vs-Build Position

The corpus's own verdict:

Kit merchandising is built; only the bundle pricing plumbing is ever rented, and the theme still has to render around it.

That qualifier is earned. Build-your-own shipped three ways across two storefronts — a collection-template palette builder, a metaobject-configured second engine with per-category caps and a reserved gift slot, and elsewhere a bought bundle app we placed and de-conflicted. Where the app was bought, the theme still carried the cart: an earlier generation of that cart read each bundle child's real price through the app's snippet, because Liquid's item.price is wrong for a bundle child. Renting the pricing engine is defensible; it does not end the work. See the fixed bundles and multipacks decision.

The Builds

Five of the 23 have published pages. Of the other 18 — the rules engine, the second bundle PDP serving 56 kit templates, the ingredient breakdown, the contents and rationale modules, the trial-kit cart gate — fifteen are documented and to follow. Three won't get pages of their own: two are folded into build pages already published, and one didn't survive editorial review.

Nudestix

• A collection template turned into a palette builder that carts one priced SKU — a collection page turned into a fixed-price palette builder; one priced SKU, picks carried as properties. High complexity, collection and cart.
• "Save With Sets": shade-selectable kit contents on the component product's page — linked kits on each component's product page, a shade picker per component, one add-to-cart. High complexity, product page.
• A second product template whose add-to-bag switches between one cart line and several — a second product section switching between a standard product form and a multi-line bundle form on which metafield is populated. High complexity, product page and cart.
• Price snippet with a bundle 'value' line and opt-out labelled price links — the merchandising fact Shopify has no field for: what a kit would be worth bought as separate products. A product metafield puts that line beside the price inside Dawn's own price snippet, so a set reads as a product with a value rather than as a discount, and it reads that way everywhere the theme prices a product rather than only on the kit's own page. Low complexity, product, listing and search.

Three Ships

• Hand-authored per-market JSON-LD for the Bundles & Kits collection — the machine-readable half of merchandising kits as products. A theme emits no entity graph for a collection page, so the collection the sets live on carries a hand-written one: breadcrumb, collection page, an ItemList of the kits with an offer and a category each, and the six questions shoppers ask about them — authored twice, once per storefront domain. Medium complexity, collection.

LUS Brands contributes two gated builds, and neither is a kit template: that storefront merchandises sets through PDP rails rather than dedicated kit pages. It is the clearest evidence here that the capability is a spectrum, not a feature.

What This Rests On

• Liquid section schema and settings — the most-used primitive here; contents, rationale and breakdown modules are all merchandiser-authored blocks.
• Metafields — 10 builds; kit composition, component lists, value figures and per-promotion configuration.
• Cart AJAX API — 10 builds; the add path, the line-item properties, and the in-cart edit flow.
• Metaobjects — one record per promotion, replacing five loose metafields that could disagree.
• Theme blocks and app blocks — per-component authoring, and the vendor widgets that sit in the same buy box.
• Custom elements, JSON-LD, Shopify Markets — the builder components, per-market collection structured data, and CA/US price display.

What Varies by Storefront

Theme base sets the floor. LUS Brands runs Dawn 15.4.1, Nudestix runs Dawn 6.0.2, and Three Ships runs Palo Alto 5.8.0 by Presidio Creative — a paid premium theme, which is why the bundle PDP there is a second, Dawn-derived section kept deliberately outside the vendor's block system rather than a rewrite of it.

Catalog shape decides the rest, and it decides more here than anywhere else in the taxonomy. A shade-led cosmetics kit is unsellable until the shopper picks a shade for every component, so the entire modal, swatch and variant-resolution apparatus exists on that storefront and nowhere else. A skincare kit's components are distinct formulas with different actives and different times of day, so the work went into per-component ingredient cards, usage timing and supporting statistics — information, not interaction. A haircare catalog sells sets as rails on an existing product page, so there is no kit template at all.

Who owns the cart is the third variable. One storefront's cart is app-owned, so a trial-kit one-per-cart gate has to re-check on the app's cart-change event rather than only on load, and re-rendering the buy box after that event meant a hand-written prepend on the theme's compiled runtime bundle — there is no supported hook inside a minified vendor build.

Where This Gets Hard

Forking is the first standing cost. A dedicated bundle product section is a fork of the main product section, more than a thousand diff lines from it, so every change to the primary product page has to be considered twice. The fork keeps the highest-traffic template free of bundle conditionals; this is the bill.

Flat schemas are the second. With no metaobject behind the ingredient data on one storefront, a kit page is authored block by block — ingredient one, two, three; percentage one, two, three — fast for a merchandiser, unbounded for the theme. Seasonal kit pages retire but keep their configuration: one section carries 28 template instances, 7 of them enabled.

Third, and least visible: a shopper-composed set is not something the platform stores. Shopify has no native notion that a line item is a set, so the contents travel as line-item properties and the key that maps a cart line back to the selection that produced it is held in the browser. Clear that storage, or come back on another device, and the line is still there at the right price — but the set can no longer be reopened and edited. A durable cart line and a durable editing session are not the same thing, and the platform makes you pick one.

And one limit here is ours rather than the platform's. On Nudestix the same shopper task — assemble a set, then buy it — is implemented twice: once on a collection template and once on a dedicated bundle product template. Each was defensible on the day it shipped. Together they are two code paths for one job, two places a change has to land, and we would argue now for one builder with two entry points.

So there are cases where we say don't build. If your kits are a few fixed SKUs with no per-component choice and no ingredient story, Shopify's bundle tooling and your product template suffice. If the real requirement is pricing — tiered discounts, per-category rules, subscription-aware math — rent that engine; it is the half that is hard to build and cheap to buy. And if nobody will keep dozens of block configurations current, an app with a data model ages better than a section nobody updates.

Related Capabilities

• Metafield-driven PDP content blocks — the authoring model kit composition and copy are built on.
• Variant-aware content and media — the per-variant machinery the shade-selectable kits reuse.
• Filters, faceted navigation and progressive grid loading — the collection templates the bundle builders are mounted on.

The rest of the Bundles, Kits & Subscriptions category — build-your-own bundles, bundle pricing and tiered discounts, subscription purchase options — sits beside this one in the taxonomy. The hubs linked above are the ones with published evidence today.

Answers to Help You Make Smart Decisions

Do I need a bundle app to sell a kit on Shopify? Not to sell one. A kit can be an ordinary product with its own price and inventory, with the component list held in metafields and rendered by the theme. Apps earn their fee when the pricing is the hard part — dynamic per-component discounts, tiered rules, subscription interactions. Presentation, contents and the buying decision are theme work either way.

How does the shopper's kit selection reach the warehouse? As line-item properties on the cart line. One storefront flattens the component titles into a single hidden property; another writes a readable line per pick plus the variant ids and a generated bundle id. Those properties render in the cart, on the order confirmation and in the merchant's order view, which is what makes pick-and-pack possible without a bundle app.

Can each component of a fixed kit have its own shade or size? Yes, and it is the most expensive thing on this page. The kit's own variants cannot express 'shade per component', so each component gets its own picker with the variant data inlined beside the swatch, and the submit still resolves to the kit's single variant. Budget for the modal, the drill-down and the sold-out states, not just the picker.

If I buy a bundle app, is the theme work finished? No. In this corpus the storefront that bought one still needed theme code for the cart — reading each bundle child's real price back through the app's own snippet, and locking quantity and remove controls on component and gift rows — plus a buy-box refresh whenever the app mutated the cart. The app owns pricing. The theme still owns what the shopper sees.

Ready to Make Your Kits Look Like Products?

A kit that reads as a discount gets bought like one. Contact us today and we'll tell you which part of your bundle problem is a pricing engine you should rent, and which part is the page you should own.