yampa · yampa · 2021–present
How business strategy, user research, and an AI-first workflow turned a struggling SaaS around.
Staff Product Designer · Design Manager
Context
The typical yampa user is a small business owner. Someone running a bakery, a store, an agency. Financial control is one of a dozen tasks competing for their attention, and it almost always loses to the core business.
The real pain isn't lack of time. It's prioritization: they can't see how a well-managed financial routine would change their company's trajectory, so they never give it the attention it needs. The product had to prove that value before asking for effort.
There was a second layer of complexity. yampa served two very different audiences: clients coming from 4blue, a financial education company whose courses had already made the pain visible, and open-market users arriving with much lower awareness. Same product, two completely different starting points in the journey.
Phase One — Business Strategy
When I joined, yampa was fully dependent on its parent company, with a pricing model that didn't scale.
Before touching any screen, I worked with the CEO on the business itself. We introduced a tiered subscription model designed around how much guidance each segment actually needed. Users with higher awareness could self-serve. Users with lower awareness needed more hand-holding, and were willing to pay for it.
Pricing is design. The way a product charges shapes how people use it, what they expect from it, and whether they stay. Revenue grew significantly without a proportional increase in subscribers.
Phase Two — yampa 2.0 and the decision that wasn't made
The 2.0 was a complete rebuild. New experience, new architecture, mobile-first.
We did the research properly. Dozens of interviews. We mapped two core profiles: entrepreneurs by opportunity, who inherited the business or chose a field they loved, and entrepreneurs by necessity, who started a company because there was no other option. Within each, larger operations usually had someone dedicated to finances. Smaller ones, the majority, did everything themselves.
Usability testing revealed our blind spot: the users willing to participate were almost always 4blue clients. Our research sample was biased toward the audience that already understood the value.
Then came the decision that was never made. The product needed to choose: build for the 4blue client, further along the journey, or for the open-market user who needed convincing first.
I raised this repeatedly. I presented the segmentation data, pushed for a decision in product reviews, and lost that argument more than once. Focus kept switching between the two audiences, and each pivot diluted the product's personality a little more, until it connected with neither.
Looking back, I should have pushed harder and earlier, when the cost of choosing was still low. That's on me too. After two years of work, one week before launch, the 2.0 was cancelled due to critical technical debt. The indecision had cost us the time the technical foundation needed.
Phase Three — The AI-First Rebuild
Losing two years of work forces clarity. We couldn't afford another two-year cycle, so I changed how the work itself was done.
I introduced an AI-first workflow: I think through the problem with Claude before opening Figma. Intent, edge cases, specs. Then I design, and build the React components myself with Claude and Cursor, shipping directly to the repository. No handoff. The person who designs is the person who ships.
This isn't prototyping with AI. It's production code: the new home (the screen in the hero above), the full cash flow module, transaction listing, navigation. I designed and implemented all of it.
For scale: the new home alone would have taken at least a month of back-and-forth in the old process. Working this way, it took three days.
The entire frontend was rebuilt in two months. The design-to-production cycle dropped by 70%, and design decisions stopped dying in translation.
Impact
Beyond the numbers: the design system was adopted by the full engineering team, and event tracking was instrumented across the product, so decisions came from activation, adoption, and churn data instead of opinion.
MRR growth had many parents: sales, marketing, and market timing all played their part. What I own directly: the pricing architecture, the product experience, and the delivery speed that made iteration possible.
People
Many people came and went through this project. A few stayed long enough to grow with it — and that growth was the best part of the work.
Lauren, Silas, and Matheus showed up every day and became sharper, more resilient collaborators through every pivot and restart. Watching that evolution was worth more than any launch.
Bruno and Rapha held the strategic direction through the hardest moments. The decisions weren't always easy, but they were always made.
To everyone still building yampa — good luck with what comes next.
Learnings
A product that doesn't choose its user ends up chosen by no one. The 2.0 didn't fail because of design or engineering. It failed because a strategic decision was postponed until it was too late. I now push for that decision on day one, even when it's uncomfortable.
Research follows the same rule: if your willing participants all come from one segment, you're not learning about your market. You're confirming your bias.
And speed changed meaning for me. With AI in the workflow, the trade-off between fast and polished collapsed. The bottleneck isn't building anymore. It's deciding what deserves to be built.
Want to talk about how this workflow could work for your team?
Get in touch →
