Loading
This should only take a moment.
Solo product design with founders and engineers, focused on turning a technical billing problem into a clearer product story.
Problem
Teams wanted usage-based pricing, but each pricing change still needed engineering time.
Solution
I designed Togai from scratch across usage ingestion, pricing setup, invoicing, and real-time insights, then shaped v1.5 into a reusable system.
Outcome
The team shipped MVP and v1.5, demos became easier, components scaled across the product, and Zuora acquired Togai.
Impact
Product
I designed Togai across usage ingestion, price plans, billing, invoices, insights, and no-code flows so the team could ship the MVP.
System
For v1.5, I built the component system for inputs, states, modals, navigation, and icons. Engineers reused patterns across the product.
Sales
The redesign made complex pricing easier to explain. Sales could demo Togai without walking through every setup step.
Design work
Usage arrived in inconsistent shapes. I made ingestion feel predictable without hiding the detail finance teams needed to trust.
I gave teams room for real pricing models while keeping setup from turning into custom work.
I separated the decisions users needed first from the configuration detail they could open later.
I designed billing details to answer “why did we bill this?” before teams traced calculations by hand.
For v1.5, I moved the work from one-off screens into a component system covering inputs, states, modals, navigation, color, and iconography.
Image carousel
Core product workflows
Usage meters, pricing setup, customer schedules, invoices, and no-code flows turned billing logic into product surfaces.
1 of 7: Redesign of components with scalability in mind - Reusable states, cards, tables, alerts, and controls gave the product a stable UI base.
Why it mattered
Togai started from billing pain the founders had already lived through. Their payments platform processed about $30B a year, but a third-party usage-pricing tool failed them and caused direct losses through incorrect billing.
They built an internal version, then saw the larger pattern: companies charging by usage were spending engineering time and budget on billing tools that customers did not value.
My design challenge was to make setup, usage review, and billing checks legible enough for teams to launch and change plans without rebuilding the product each time.
My role
No design system, no prior product, no pattern library. I was building structure and language while the founders and engineers were still deciding what Togai should become.
In the room from day one. I joined founder calls, heard how companies described their billing problems, and later spoke with users who got stuck while configuring price plans. That input went straight into the next iteration.
Small first, built to last. I pushed for the smallest useful version, then returned to the parts causing friction. The first release had to ship and teach. v1.5 needed a system the team could keep building from.
Design stayed close to engineering. We made decisions in the room, so I could adjust while the product took shape instead of waiting for a spec cycle to expose the problem.
Key decisions
Keep the first release narrow
I kept the first release narrow so the team could learn from real setup behavior before expanding the surface.
Make billing logic visible
I kept the billing structure visible where finance and engineering teams needed to trust the numbers.
Break setup into smaller steps
Users were configuring billing, not authoring a pricing engine from scratch.
Move from screens to components
I pushed reusable components before v1.5, then formalised them into a design system.
Keep what worked
For v1.5, I revisited the flows users struggled with and kept the proven patterns intact.
Image carousel
Price plan setup flow
Before and after screens trace the flow from plan basics to configured rate cards and the final detail page.
1 of 10: 1. Creating a plan [MVP] - Teams entered plan name, billing cycle, currencies, grace period, and trial rules on one long setup screen.
What customers said
Togai turned a pricing launch that would have taken months into something the team could ship in days.
Within the first month it was clear the platform was working, and the ROI was there from day one.
Reflection
Money products turn trust into a design constraint. We learned that on an early price-plan flow. It reached testing, then we dropped it because users had to hold too much context before making one decision. Ambiguous labels, unclear states, and missing confirmations became trust failures. That shaped the component system.
As I grew as a designer, I valued proximity to founders and engineers. Product decisions happened there.
From people I worked with
I worked with Kishore across multiple products and domains, and he has a sharp instinct for how design drives business outcomes. He prioritizes clarity and simplicity, and he moves quickly enough that he feels like a 10x product designer in practice.
Kishore designed the Togai UI from scratch and worked through a system with many configurations and use cases. He simplified complex details clearly and iterated fast enough to help the product reach best-in-class UX for a billing platform.
