Preserving configurable pill case bundles across Shopify
- 01Rebuilt the storefront configurators for combined cases, BYO packs, MagNano, Magnetic Sets, and Monthly bundles.
- 02Implemented versioned bundle contracts across the theme, Cart Transform, and cart and checkout validation.
- 03Connected bundle pricing and promotions to checkout savings, preorder notices, and customer account reorder actions.
Role
Shopify developer across storefront and commerce logic. Custom commerce work across an existing theme and three Shopify app repositories. Codebase inherited storefront with custom configurators modernized incrementally.
Scope covered
- Shopify Online Store 2.0
- Cart Transform
- Cart and Checkout Validation
- Discount Functions
- Checkout and Customer Account UI Extensions
Context
Ikigai Cases sold metal pill organizers as individual cases and configurable sets. Its product families included combined cases, build your own packs, MagNano, Magnetic Sets, and a Monthly bundle of four Weekly Cases.
A shopper could select independently stocked colors, a case count, engraving, replacement lids, or packaging. Those choices described one purchase, but they could involve several physical variants and separate engraving products. I needed to preserve both the configuration a shopper understood and the merchandise identities used by Shopify's downstream order surfaces.
My role
I worked across an inherited Online Store 2.0 theme and three custom Shopify app repositories. I rebuilt configurators, implemented bundle markers and cart operations, and connected the resulting lines to validation, promotions, checkout displays, and reorder actions.
The underlying theme and Shopify app scaffolding were existing foundations. Shopify supplied cart, checkout, inventory, and order primitives. My scope was the custom behavior that connected those surfaces. I also preserved the Intelligems attributes needed on expanded lines; the experimentation service itself was an external dependency.
The actual challenge
The product families needed different cart operations. Treating them as one generic bundle would have hidden distinctions that affected prices, component relationships, and later interpretation of an order.
| Contract | Product shape | Cart operation |
|---|---|---|
com2 | Single combined case with extras | Merge selected merchandise lines |
com3 | Morning and evening or two week case | Merge physical components and extras |
mag2 | Configured MagNano set | Expand a selected tier parent |
mset2 | Magnetic Set of one to four cases | Expand into cases, extras, and packaging |
byo2 | Build your own pack | Update prices on nested physical cases |
mon2 | Monthly bundle with four cases | Distribute a bundle price across nested cases |
Historical shapes also remained relevant. I retained selected legacy readers, but compatibility was specific to each path. The nested BYO replacement had a coordinated cutover runbook because its previous writer and new readers were not interchangeable.
System design
I used _ikg_bundle as a versioned identity carrying a family, bundle instance,
and roles or slots specific to that family. I kept visible engraving and
preorder details explicit so later surfaces could display them.
The marker identified a contract; it did not authorize a price or prove that a group was valid. For nested BYO and Monthly bundles, I checked native parent relationships as well as markers. For merged and expanded families, I provided readers for the resulting merchandise and attributes.
I kept pricing rules specific to each family. BYO case tiers and the Monthly bundle target came from money metafields queried by the Functions. MagNano and Magnetic Set case allocations began with the selected parent's Shopify price, while their add ons used captured amounts from the configuration payload. The shared protocol carried those different authorities explicitly instead of flattening them into one ambiguous price field.
Storefront configuration and inventory
I built gated configuration steps that unlocked dependent choices after confirmation. Changing an upstream choice reset affected selections, and the Add to Cart action checked whether the required steps were complete.
For Magnetic Sets, availability depended on the role layout as well as color. A set with four cases required two middle components. I aggregated demand for repeated variants, subtracted quantities already in the cart, and refreshed product data for each role and cart data before submission. Shopify remained the final inventory authority at checkout, while the configurator prevented selections already known to be invalid in the shopper's current cart.
I used product references, metafields, and metaobjects to supply configuration
data. A shared search template returned JSON tailored to each family, while
theme.productDataFetcher shared concurrent requests and cached responses for
the page lifetime. Its invalidation methods let consumers request fresh data.
Errors were cached too, so retry behavior depended on deliberate invalidation.
The configurators also exposed selection, expansion, validation, and live status
attributes through consistent component state.
Pricing and cart integrity
I dispatched the six current families through one Cart Transform entry point. For expanded sets, I split the parent's case total in integer cents and assigned the remainder to the final component. For nested bundles, I updated case prices without replacing the physical merchandise with a synthetic stock item.
Currency handling followed each contract. BYO and Monthly converted money metafields with the supplied presentment rate and rounding configuration. Magnetic Set add ons used captured currency amounts, base amounts, or a compatibility scaling path. I kept those branches explicit instead of treating every amount as the same kind of price.
I added a separate validation Function for byo2 and mon2. BYO checks covered
authorized carriers with a zero price, complete logical slots, child relationships,
quantities, gift allowances, and usable case tier prices. Monthly added exact
catalog and SKU checks, four cases of one size, and allowed engraving identities.
Unrecognized attached children invalidated these groups.
A rejected transform returned no pricing operation. For the two nested contracts, the validation Function could also return a checkout error. I kept those protections separate because transformation and checkout validation have different responsibilities.
Promotions, checkout, and reorder
I connected Free Nano eligibility to bundle structure, including validated
nested children, variant exclusions, and the cheapest eligible standalone Nano
for the manual gift path. A separate LABOR Function handled engraving discounts.
The transform supplied _ikg_labor totals for merged combined cases; expanded
MagNano and Magnetic Set discounts used an engraving catalog maintained in code.
The Free Nano delivery target addressed the first delivery group when its
discount instance included the shipping class.
At checkout, I made savings readers recognize line shapes specific to each family and discount allocations. The nested readers used contextual case prices when available and returned neutral bundle savings when that context was absent. Magnetic Set deliberately retained the actual line total with zero calculated bundle savings. A separate extension read preorder attributes from child lines.
For reorder, I separated ordinary merchandise from protected configured groups. Ordinary eligible items used a bounded payload and a theme cart handoff. Configured groups returned to a current configurator instead of replaying their transformed components. Mixed or unavailable orders used a review action.
Result
I brought six current bundle families behind one dispatcher and added dedicated checkout validation for the two nested contracts. In September 2026, 689 tests passed across transformation, validation, discounts, checkout savings, preorder parsing, and reorder logic.
The rollout records captured production acceptance for Magnetic Set in July 2026 and an active Monthly writer in September 2026. BYO kept a staged cutover because its old and new contracts were not interchangeable. Together, those changes gave each product family a defined path from storefront configuration to the downstream surfaces that needed to understand it.
Takeaway
I made the system easier to reason about by preserving the distinction between a configured purchase and its physical merchandise. A shared identity connected the surfaces, while pricing, validation, and reorder behavior specific to each family made each boundary explicit. The transferable principle was to share the contract without pretending that every product shape had the same authority or failure behavior.