Building bundles into the platform, not bolting them on

Advanced bundling often depends on third-party apps, even on established commerce platforms. Shopify offers its own Bundles app for fixed bundles and multipacks, while more customized experiences can use third-party apps or custom development. Those integrations can introduce inconsistencies across storefront, cart, checkout and back-office workflows.

For Fluid’s clients, starter packs were a requirement. Our workarounds sometimes produced incorrect prices or incomplete product pages, and shoppers couldn’t change a pack’s preset contents. Building bundling into Fluid gave us a way to address those needs as part of the platform.

We started with a simple capability: combine multiple products into one bundle. Real client requirements gradually expanded it. A fixed kit, a customizable box and a subscription pack needed different rules, but merchants shouldn’t have to configure every option to sell any one of them.

Ordinary product setup centers on details, media and publishing. Bundles added decisions about what shoppers could choose, how selections affected price, and whether the resulting purchase worked across countries and inventory settings.

Another designer and I used customer research and quick prototypes to make the case that one builder could accommodate different client configurations. I owned the design, with feedback from our art director and engineers on feasibility.

Four implementation specialists used the prototypes repeatedly; four other employees and six clients also participated. Open-ended exploration and focused bundle-building tasks shaped the design, especially bundle-wide pricing and country availability.

A single bundle could contain several groups, each with independent rules. Some used one fixed price; others calculated a price from the customer’s choices. Merchants could preselect a variant, allow or require subscriptions, and ask customers to select an exact number of items, a minimum, a maximum or a range. Quantity limits and mutually exclusive groups added another layer of flexibility.

That flexibility risked making ordinary setup intimidating. I kept optional advanced settings off by default, revealing their dependent fields only when merchants opted in. In this group, enabling quantity limits opens the per-item controls. Simple bundles stay lightweight, while more specialized merchants can configure the rules they need.

The toggles themselves remain visible and discoverable. The same principle applies to optional bundle-level pricing and inventory: additional configuration appears when the relevant setting is enabled, rather than exposing every field at once.

Pricing was confusing in the early design. Clients selling a fixed pack needed a clear way to set one price for the whole bundle, rather than price each group separately. I added an optional bundle-wide pricing setting for that task.

Group-level pricing remained available: fixed pricing for a predictable offer, or dynamic pricing that adjusts with the shopper’s selected items and options. The pricing scope could fit the merchant’s offer instead of forcing different businesses into the same setup.

Country availability originally lived within individual groups. Feedback showed that this made it too easy to choose products that didn’t work in the bundle’s intended countries. I moved availability to the bundle level: admins could only add products available in every country selected for the bundle.

Later edits mattered, too. If a country change made an existing product invalid, the designed save-time error required admins to resolve the conflict before saving. Country pricing also needed to follow that availability, whether the price came from the bundle or its groups and selections.

I designed a reusable storefront theme alongside the admin builder. Merchant rules had to become clear purchase choices that made sense from the product page through cart and checkout, including subscriptions for individual products or the whole bundle.

In this example, shoppers choose seasonal flavors, a spoon and one add-on bundle. Defaults and completion indicators make requirements visible, and add-to-cart stays unavailable while required selections are incomplete. The theme needed to explain what was included and what could change without asking shoppers to interpret the admin settings.

I used Claude to build working prototypes, iterated in code and submitted pull requests. Engineers could use those changes or refer to them during implementation. I remained responsible for the design decisions, revising them with engineers, our art director, implementation specialists and clients.

Native bundling is in use by clients and helped retain businesses that would otherwise have left Fluid. It gave them a platform capability for selling starter packs and accommodated more merchant scenarios as their requirements grew.

I estimate that the feature helped retain about $50,000 in monthly revenue over a six-month period. That figure is my estimate of revenue from retained accounts, not an audited measurement or new revenue generated by the feature.

Additional transaction revenue was estimated at approximately 5%. This was an estimate, not a measured gain or a guaranteed result.

I would start more user conversations before designing. Quick prototypes helped us get the project approved, but earlier input would have given me a stronger foundation for the expanding requirements. The lasting design lesson was to make room for complexity without making every merchant work through it.