Packages

The problem

GlossGenius is the all-in-one platform beauty and wellness pros use to run their businesses, from booking to payments to their website. When I picked up Packages, the company was pushing upmarket, moving from solo professionals to larger teams and into new verticals like med spas. Packages was one of the main features standing in the way.

A package lets a business sell services in bulk at a discount, so a client buys five massages up front and redeems them over a few months. In beauty and wellness that is how a lot of businesses drive cash flow and keep clients coming back, and in the verticals we were trying to win it is simply expected. The majority of med spa and massage businesses offer them.

We didn’t have it, and every major competitor did. Our sales team kept losing deals the moment a prospect asked “do you support packages?” and heard no. So this wasn’t a nice-to-have, it was the wall between GlossGenius and the customers it wanted to grow into.

the #1 reason we were losing upmarket deals

What I built, and the calls I’m proud of

I owned Packages from discovery through launch, and it turned into one of the most technically demanding projects I’ve worked on.

Packages, not bundles. Customers lumped two things together: packages (services redeemed over time) and bundles (services used in one visit, like a spa day). I chose packages. They were requested about three times more often, we already had rough workarounds for bundles and nothing at all for packages, and packages meant building real payment architecture, the same foundation memberships, loyalty, and subscriptions would need later. One feature, but also the groundwork for a whole roadmap.

Foundation first, convenience second. I scoped the first version to in-person purchases at the business, and made self-service purchasing on the booking website a fast follow. The question I kept coming back to was, what do we have to build no matter what, and what can we layer on later. In-person selling delivered real value on its own and set up everything after it. So customers waiting on website purchasing weren’t stuck in the meantime, we ran a two-week sprint to surface packages on their websites with a contact button, which handled discovery while we built the real purchase flow.

Stepping into payments cold. Three weeks in, the payments PM I was supposed to partner with left the company. Rather than let the project slip, I took over the entire payments workstream myself, refunds, transaction reporting, compliance, all of it, with no prior payments background. Payments is unforgiving and customers feel every mistake, so the pressure was real. It was one of the most challenging, and rewarding, aspects of the project.

Building toward memberships. Because I built Packages as payment infrastructure and not just a feature, it became the base for Memberships, recurring plans with credits and perks. I ran the discovery for Memberships and owned it into execution too, up until I left the company.

senior judgment: solve the deal-blocker and lay the platform for what’s next

The end-to-end

Discovery ran about one to two months: customer interviews about how businesses actually price and use packages, competitive research (packages are table stakes in med spa and spa, so I needed to know exactly what customers were getting elsewhere), and a lot of time with the sales lost-deal data to put a real cost on the gap.

The most useful thing I learned came from pushing past what customers first told me. They described packages as a way to win new clients, but when I dug in, packages were really a retention tool, existing clients pre-paying for convenience and savings and committing to come back. That reframing changed how we positioned it, and how I thought about related features like memberships and client loyalt programs.

Execution ran about six to eight months and pulled in more than 30 engineers across four product and engineering teams. Most of my job was keeping that coordinated, sequencing the work, and making the trade-offs that kept us shipping (even when it meant admitting I'd overscoped).

30+ engineers, 4 teams, and the discovery to know what to actually build

What it did

Packages crossed $1M in transaction volume in its first three months, and closed the feature gap that had been blocking our biggest deals. Early adoption grew 80% over that window. Just as important, it laid the payment foundation for the next set of blocking features, such as memberships and client loyalty programs.

What I learned

Two honest things. About halfway through I realized I had over-scoped the launch with reporting and activity-tracking features that weren’t essential to the core use case. I owned it, moved them into clearly labeled fast follows, and made sure we kept logging the data so we were only delaying the interface, not losing history our customers cared about.

Taking on payments with no background in it was genuinely hard. But it is the clearest proof I have that I’ll step into whatever the project needs, learn it fast, and earn the team’s trust while I do.