Building the starter packs our clients needed

For many of our clients, starter packs were a non-negotiable part of their business. Fluid didn’t have a proper way to support them, so we relied on workarounds to group products together.

That created problems on both sides of the experience. Prices weren’t always correct, the product page didn’t always show everything in the pack, and customers couldn’t choose between options. Each pack had to be sold with a preset list of products.

I wanted to support those needs directly: let clients decide what goes into a pack, what customers can choose, and how the bundle should be priced.

The initial concern was that one bundle builder couldn’t handle the range of configurations our clients needed, and that the underlying logic wouldn’t work in practice.

Another designer and I advocated for the feature through customer research and quick prototypes. Instead of discussing bundling only as an idea, we could work through the configurations clients needed and demonstrate how they could fit into the product. I did the design work myself, with feedback from our art director and input from engineers on what was possible.

Four implementation specialists used the prototypes repeatedly. Four other employees and six clients also took part as I developed the design.

I used a mix of open-ended sessions and specific bundle-building tasks. Sometimes people explored the builder on their own. Other times, I asked them to create a particular configuration. The open-ended sessions gave them room to use the tool in their own way, while the focused tasks let us work through specific requirements.

Feedback from both shaped the design. Two changes were especially important: making bundle-wide pricing easier to set up and moving country availability out of individual groups.

Pricing was confusing for people using the early design. Fixed and dynamic pricing gave them flexibility, but clients also needed a clear way to set the price of the whole bundle instead of pricing each group separately.

I added a bundle-wide pricing option for that task. Group-level fixed and dynamic pricing remained available for configurations that needed it. That gave clients a choice between pricing the pack as a whole and setting prices within its groups.

As we worked through more client needs, I also expanded the selection options so companies could decide what to include themselves and what to let shoppers choose.

The first version handled country availability within individual groups. Through feedback from clients and implementation specialists, we found that this made it too easy to choose products that didn’t work for the bundle’s intended countries.

I moved country availability to the bundle level. Admins could only add products available in every country selected for the bundle.

I also accounted for later edits. If an admin changed the bundle’s countries and an existing product no longer met those requirements, the interface showed an error when they tried to save. They had to resolve the conflict before saving their changes.

The checks covered both adding products and changing the bundle later, rather than leaving admins to keep track of every product’s availability themselves.

The admin builder was only half the work. Clients needed a customer-facing experience that could display the bundles they configured, so I designed a reusable storefront theme alongside it.

The theme needed to explain what was included, what could be changed, and what still needed a selection. In the example shown here, shoppers choose seasonal flavors, select a spoon, and choose between add-on bundles. A default selection and completion indicators help show which requirements are already met. The add-to-cart action stays unavailable while required selections are incomplete.

The design also includes subscription choices for individual products and for the bundle as a whole. These different configurations needed to fit within the same theme without making shoppers interpret the settings behind them.

I mostly used Claude to build working prototypes, then iterated in code and submitted pull requests. Engineers could use those changes or refer to them as they implemented the feature.

This let me work through the interactions in a prototype while staying in touch with engineers about what was possible. I remained responsible for the design decisions and revised the experience with feedback from the art director, implementation specialists, and clients.

Native bundling helped us retain clients who would otherwise have left the platform. For those clients, being able to sell starter packs was a requirement, not an optional improvement.

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.

I would spend more time talking with users before starting the design. We were also trying to get the project approved, so we worked with the time and resources we had and used quick prototypes to move the conversation forward.

The repeated sessions were still an important part of the work. Starting more of those conversations earlier would have given me a stronger set of requirements to design around from the beginning.