While working in sales, I saw how difficult it was for me and reps to understand what their next paycheck would be. Commission structures were complex, tracking was manual, and mistakes were easy to make.

I partnered with a colleague to build Sales Tracker, an iOS app that helped reps track sales, commissions and expected earnings in one place. We self-funded the product and designed and shipped the first version in six months, iterating quickly because we were working alongside the people using it every day.

I designed the product from the initial idea through launch, including the core flows, product logic and go-to-market materials. The app reached 64 paying subscribers in its first month. It still has active users seven years later.

Sales Tracker was also the project that pushed me toward product design. I became interested in spotting real problems, turning them into useful products and seeing how software could scale a solution beyond the people immediately around me.

The product focused on a simple question: how much will I get paid?

Sales Tracker automated commission calculations, tracked goals, and helped reps verify their payslips using a structure that mirrored the way they already worked.

One of the more complex cases was split payments. A sale could count toward the month it was closed, while the commission itself was paid across two different paychecks.

The app handled those calculations automatically, reminded reps when the second payment was due, and made split payments visually distinct so they were harder to miss.

For the first version, we tailored the payout logic to one hotel.

That meant reps could open the app and immediately see accurate numbers with almost no setup. It helped us gain early adoption because the experience felt effortless.

The trade-off was scalability. Once word started spreading beyond the original team, it became clear the product needed to support different companies, departments and commission structures.

Opening Sales Tracker to other industries meant users now had to configure their own commission rules.

The challenge was collecting enough information to calculate payouts accurately without turning onboarding into a long setup process.

I used progressive disclosure to keep the flow short by default and only ask additional questions when a user's commission structure required them.

The same principle carried into logging a sale, where only the fields relevant to that specific sale were shown.

When I revisited the product after studying UX/UI, I realized we had gradually tried to solve too many problems at once.

I interviewed five long-term users and found that many features were either rarely used or never discovered.

I cut the product back to the 20% of features users actually valued and returned to the question Sales Tracker was originally built to answer:

How much will my next paycheck be?