I take the products nobody can describe the same way twice.

1. Where I started

   I am from Visakhapatnam, a port city on the Bay of Bengal. It is a working coast, cargo and a shipyard, with a university sitting in the middle of it. [check] I studied there, and while I was still a student the city itself became the client: a state event, a fixed brief, a team of six, and a date nobody could move. [check on "first client" framing] Public work with a hard date taught me faster than any critique did. [check]

2. The road

   California came next, for a master's I took because I wanted to know how the thing actually gets built. [check] Dallas is where I shipped what I drew, so the design and the code stopped being two jobs, and Minneapolis is where nothing arrived as a brief, so I learned to read the requirements and the data before drawing anything. Bengaluru is where the work stopped being screens and became patterns other teams inherit, most of them people I never met. Now I am based out of India and I keep moving, which costs the work nothing: the team is in another country either way, and the file opens the same in any room with a door.

3. How I work

   I go looking for the workaround before I read the brief, because the document everyone quietly stopped opening says more about a product than the one everyone signed off. I build in the real medium early, since a schema with forty objects only shows what is wrong with it once you can click it and change it. What I want to leave behind is a decision a team can repeat without me, and that is the part I am slowest at: writing the rule down takes longer than drawing the screen, and I have shipped the screen first more than once.

4. Off the desk

   Away from the desk I am usually [a thing he does], and on a good weekend [a second thing he does, with where or with whom]. I keep going back to [a subject he follows for no professional reason], which has nothing to do with the work and does not need to. Ask me about [a thing he will talk about for too long] and you will not get a short answer.

5. Particulars

   Tools

   • Figma

     I draw in it, then export tokens from it so engineers consume a value instead of guessing it.

     Figma

   • GSAP

     Heavy for what most sites need, and still the only timeline I can read back months later.

     GreenSock

   • Claude

     It builds the parts of a prototype I would otherwise skip, and it is confident when it is wrong.

     Anthropic

   • Notion

     Where the specs live. Slow to open, and still the only place the whole team looks.

     Notion

   Reading

   • The Design of Everyday Things

     TODO example — I reread the chapter on affordances every time I am tempted to add a tooltip.

     example

   • Thinking in Systems

     TODO example — The clearest book I have found on why fixing one screen moves the problem somewhere else.

     example

   • Shape Up

     TODO example — I disagree with the six week cycle and still use its way of writing a pitch.

     example

   Listening

   • Design Details

     TODO example — Two designers arguing about small decisions, which is most of the job.

     example

   • The Pragmatic Engineer

     TODO example — The closest thing I have to a window into how engineering teams actually decide.

     example

   • 99% Invisible

     TODO example — Long episodes about design that has nothing to do with software, which is why I keep it.

     example

   Outside

   • Bouldering

     TODO example — One problem at a time, and no way to talk your way past a hold.

     example

   • Film photography

     TODO example — Thirty six frames makes me decide before I press, not after.

     example

   • Long walks

     TODO example — Most of what I have solved at a desk was actually solved two kilometres from it.

     example

6. Now

   Open to a full-time role, a contract, or a cofounder seat, on products where the hard part is the system underneath. Sep 2026