I design products, and the systems they ship on.
Ten years in product design, across AI analytics, pharma, food delivery and salon software. Three design systems since 2024, each built for a product already in front of customers, and the products shipped on them.
Two practices, two tabs
Series A · 04 sheets
Design systems
Systems built for products already in front of customers, measured by who reaches for them.
- A-01MichelangeloRe-skinning a live analytics product without a rewrite.
- A-02MeridianOne token layer, seven module identities, three presentation modes.
- A-03Talabat ProSpecifying one mobile component down to its acceptance criteria.
- A-04ProtonRepairing a bypassed library while shipping the product built on it.
Series B · 05 sheets
Product design
End to end product work, from research to an accepted design, built on the systems.
- B-01Kaiya DataOne chat that builds the Business View, replacing a pipeline and a second assistant.
- B-02Panorama 360Turning a monthly report into a daily landing page for pharma product managers.
- B-03Talabat Pro membershipMaking a membership worth its price in eight seconds, without adding a benefit.
- B-04Portfolio recommenderReplacing two-week spreadsheet analysis with recommendations a PM can check in context.
- B-05Zenoti onboardingReplacing a week of assisted setup with half an hour of self-serve onboarding.
How I work
practice/ask-the-goal-first
I start from what someone is trying to get done, not the screen they asked for. I watch or interview before I draw, and every finding sits next to the design decision it caused. At Tellius that meant two questions before Kaiya reads a single table; at Talabat, the one number a member would pay for.
practice/start-at-the-bypass
When a team works around the system, with a detached component or a hand-typed colour, I read it as a bug report. I count the bypasses before I draw anything, because the count shows where the library is harder to use than to avoid. Proton went from 12 to 85 percent adoption that way.
practice/ship-on-the-system
The product and the system improve each other. I ship product on the system, so a gap shows up as a real screen that cannot be built, and the fix lands once in the system instead of five times in product. I keep the options that lost on the record, test in working code, and measure both sides: what people do differently, and how often teams reach for the components.
About
Product design and design systems are one job: the product shows where the system breaks, and the system makes the product faster to build.
- Based
- Bangalore, IST
- Working
- Remote contracts
- Trained
- CEPT University
- Years
- 10 in product design
- Product
- Kaiya Data · Panorama 360 · Talabat Pro · Portfolio recommender · Zenoti
- Systems
- Michelangelo · Meridian · Proton
- Domains
- AI analytics, pharma, food delivery, beauty and wellness
I work on both sides of the same problem. A product team asks for a redesign, a launch, a dashboard people actually open. Underneath, almost every time, is a design system the teams do not trust. I design the product and repair the system it runs on, in the same engagement.
On the product side: Kaiya Data folded a pipeline and a second assistant into one chat at Tellius. Panorama 360 turned a monthly report into a daily page for pharma product managers. Talabat Pro, Zenoti onboarding and a portfolio recommender each started from research and ended in a measured change.
On the systems side: Michelangelo re-skinned a live analytics product without a rewrite. Proton went from twelve percent engineering adoption to eighty five. Meridian is generated from a token source, with a contrast check in the build.
The two make each other better. Product work shows where the system is being worked around; the system makes the next product decision faster to ship. Remote from Bangalore, on IST.
Reach me