Which hat are you wearing?
Pick a lens — each tab shows how I work from that point of view.
How I think about your problem
What you're building
Where I work
What customers need
read 4 learnings
Spend less on the wrong thing
The gap between what you're building and what customers need is where engineering cycles go to die. I close that gap before the sprint starts — customer evidence, fast prototypes, real feedback — so you only invest in what's already validated.
Working ≠ right
A healthy system can still produce the wrong output. Relay's infrastructure was fine. Copy quality was 70–75%. The problem was invisible until I built the eval layer. That's the kind of gap I find before it costs you a customer.
Prototype as decision
I don't hand you a spec. I hand you something customers can react to. A working prototype forces a real yes or no. ThredUp went from blocked to unblocked within 24 hours of a prototype ship. That's the loop I run.
I write the pitch too
Design work only counts if it gets built. I shaped product bets, brought cross-customer evidence, and presented to the CEO and CTO. I know how to make a case for the right thing, not just make it look good.
What I can do for a team
At Aampe, I was the whole design function for a B2B MarTech company serving Swiggy, Grab, Deezer, and ThredUp at 500M events/day scale. I ran product strategy, designed the AI workflows, built the prototypes, and validated with real customers before anything went to engineering. No hand-holding needed.
How I build
- Prototype before spec. I skip the Figma-to-spec-to-eng queue. Claude Code, Replit, Vercel — prototypes in front of real customers in days, not weeks. apps.aampe.com unblocked a ThredUp customer within 24 hours of ship.
- Follow the pain, not the feature request. Reward Functions was technically working. The design problem was that users felt terrified to touch it. That's a different problem, and it leads to a different solution.
- Ship, validate, graduate or kill. Prototypes that work earn engineering investment. Ones that don't tell you something useful. Either way, you've saved a sprint.
- I write the pitch. I shaped product bets using Shape Up methodology, brought evidence from cross-customer research, and presented to the CEO and CTO. Design work only counts if it gets built.
How I approach design work
Design decisions
Where craft lives
User reality
How I actually think
I get closest to the problem before I touch anything. Not because it's a process I follow — it's just how I'm wired. I need to know what's actually broken before I start making things.
Most of the time, the thing people think is the problem isn't. The feature request is a symptom. The customer complaint is a clue. The real question is usually a layer down. I like finding that layer.
I'm a designer who builds. Not as a party trick, but because prototyping in code changed what I can learn and how fast. You find out more in one customer session with a working prototype than in three rounds of Figma feedback.
read 4 learnings
Process over intuition
Good taste without a repeatable process produces inconsistent work. I built Shape Up sprint structures, betting tables, and design-dev handoff documentation at Aampe — so the team could move fast without losing quality when I wasn't in the room.
Design systems as infrastructure
SHARP wasn't just a component library. It was written to be LLM-readable — design tokens and pattern rules that Claude Code could consume directly. A design system that only humans can use has a shelf life. One that machines can read scales differently.
Research as evidence, not comfort
The job of research is to change your mind. I've synthesised 10+ Slack channels and 6 enterprise customers into structural product problems — not just a list of complaints. The output should tell you what to build next, not validate what you already planned.
Design that earns engineering
A design that doesn't get built is decoration. I write the pitch, bring the evidence, present to leadership. My work moves because I make the case for it, not because I'm hoping someone else will.
The quick summary
14 years of experience. Most of it in B2B SaaS, AI tooling, and startup design leadership. The last 15 months as Head of Design and Product at Aampe, a B2B MarTech company with Swiggy, Grab, Deezer, ThredUp among its customers.
I've run a design team of 4, built design ops from scratch, owned product roadmap and sprint prioritization, and shipped AI-native features end-to-end. I'm also comfortable being the only designer in the room when that's what's needed.
A few things I believe about design work right now
- Design judgment — discernment and taste — is the irreplaceable part. AI tools make artifacts faster. They don't generate the judgment about which artifact is the right one.
- The designer-PM-researcher split is dissolving. Small teams with strong product instincts and AI tooling can replace much larger traditional teams. The people who can work across all three lanes are the ones getting things done.
- Synthetic user research reflects the researcher's existing mental models back. It's useful as a speed-up, not as a substitute for actual discovery.
- Prototyping in code changed what design feedback cycles look like. You can put something real in front of a customer in the same day you got the problem. That changes everything about how you prioritise.
How I approach design work
Intended behaviour
Where I design
Actual behaviour
The gap between intended and actual behaviour is where AI products break. I design for that gap — not just the happy path. Eval layers, correction surfaces, fallback states, context scaffolds. The interface between what the system does and what the user expected is a design problem as much as an engineering one.
read 4 learnings
Alignment Drift
Agents operating without shared context diverge from original intent. This is the design-layer equivalent of model drift. I named this pattern at Aampe and built the governance structures to keep it in check — shared context, eval checkpoints, explicit boundaries.
Onstage Validation
LLMs shifted analytics design from front-loaded precision testing to real-time iterative validation. Users participate during generation now, not after. I built eval tooling at Aampe around this — scoring dimensions, live approval flows, override mechanisms.
Prefix-First Design
Cast the brief once, ship decisions in the repo, check it still holds. Open framework — the brief lives with the work so agents and humans don't re-litigate context. Published on GitHub; I use it on every AI workflow I build.
Conversation as scaffold
Humans can't give exact inputs but expect great outputs. The Prompt Shaper insight: the translation layer should be designed into the interface, not left to user skill. That's a product design problem, not a prompting problem.
How I think about systems
Generation is cheap. Knowing what to build isn't. Every team right now can spin up a prototype. The hard part is still figuring out the right thing to build, testing that assumption fast, and not wasting a sprint on something customers don't need. I've built the structures — eval frameworks, pitch templates, experimentation governance — that make those decisions less dependent on gut.
- LLM output quality as a design problem. Relay's first-pass quality was 70–75%. The quality gap wasn't the model — it was the interface between human intent and LLM input. Prompt Shaper was the design solution. Result: 90–95%.
- Prefix-First Design. Cast the brief once, ship decisions in ledgers agents read, check the brief still holds monthly. Open framework on GitHub — how I ship internal tools outside the sprint queue.
- Alignment Drift. The pattern where agents operating without shared context diverge from original design intent — the design-layer equivalent of model drift. Identified and named it at Aampe.
- Onstage Validation. LLMs have shifted analytics design from front-loaded precision testing to real-time iterative validation where users participate during generation. Built eval tooling around this.
- Conversation as scaffold. The Prompt Shaper insight: humans can't give exact inputs but expect great outputs. The translation layer should be designed into the interface, not left to user skill.
Proof
Social proof, work previews, career timeline, and stack — the same for every persona.
Testimonials
Work previews
AI work
Three ways I work with AI since 2024 — AI product design, building with AI, and team enablement.
Curious what I build for fun?
The weekend shelf — mango atlases, tiny browser tools that ship on their own with just a PRD, and builds that start as tangents and end up shipped.
Work timeline
-
Head of Product & Design — hybrid IC and leadership shipping AI workflows, prototypes, Relay, and design ops for agentic MarTech.
-
Principal Product Designer & co-founder — led a team of 3 delivering sprint-based MVPs for AI, MarTech, Ed-Tech, and FinTech startups; $0.5m/yr revenue.
- +4 more customers
-
Head of Products & co-founder of India’s first no-code agency — Framer, Webflow, and Glide MVPs via design sprints for startups and brands.
- +4 more customers
-
Design Instructor & core team — built a design and product school from scratch; 30+ cohorts, 10,000+ students, and $0.7m/yr revenue.
- +6 more clients and schools
-
Second designer at a 17-person agency — user research and prototypes for Amazon, Vodafone, and Philips across iOS, Android, and web products.
- +5 more Clients
Stack
Design, product, and AI-assisted build tools I use day to day — tap to visit.
Fitment & Next steps
Role fit and work authorisation — the same for every persona.
Roles that make sense
Strong fit
Founding designer / Lead designer: Full ownership, close to product, close to customers. You need someone who can also be the PM when needed.
AI product designer / UX for agents: LLM workflows, eval frameworks, conversational interfaces, agentic UX patterns. Done it, still doing it.
Forward-deployed designer: Translating customer pain into prototypes before engineering investment. Hands-on, fast, measurable.
Design leadership / Head of Design: Built and led design at Aampe — hiring, critique, cross-functional alignment, and a quality bar. Process that creates momentum, not bureaucracy. Still ships.
Honest gap
Pure consumer design: My primary context is B2B SaaS + AI tooling. Consumer instincts exist but aren’t the headline.
Work authorisation at a glance
Based in: Hyderabad, India (IST) — primary base, with roughly half the year in Singapore.
Remote work: Open to any time zone with async overlap. Currently working during US/EU hours.
Contract/freelance: Available immediately via HueGrid (Singapore-registered). No restrictions when contracting with non-Indian employers.
Spain: Working on securing the Digital Nomad Visa which will allow me from European timezone for 3 years.
US: B-1/B-2 visitor visa valid until 2035. Cannot be on a US employer’s payroll. Can receive US income as a contractor via my Singapore entity. Full-time US roles require employer sponsorship.
Canada: Visitor visa valid until 2033. Remote work for non-Canadian employers is permitted.
Singapore: Can be hired via Singapore entity. Open to relocation with employer sponsorship.
Let's talk about what you're building
Share what you're working on and where the design or product gaps are — I'll tell you honestly if I'm the right person. Book a call or copy my email.