Building products is what I do. But the best ideas come from the thinking that happens when I'm away from the screen — over a chess game, during a walk, or in the middle of a conversation that goes somewhere unexpected.
I don't just write code. I build products — the kind that start with a napkin sketch and end with real users, real feedback, and government receipts to prove it.
Founded a tech-tourism startup, validated 200+ users before production code, and got an AI education platform shortlisted by the Government of India. The builder mindset isn't a buzzword — it's how I work.
Chess taught me something no CS course ever did — that the best move isn't always the most obvious one, and that pattern recognition beats brute force. I think about product decisions and system design the same way I think about a chessboard: what's the position, what are the threats, and what's the move that creates the most options three turns ahead.
There's something deeply satisfying about writing code that runs close to the metal — TCP sockets, thread synchronization, memory management. Building PyKV and the distributed task queue weren't assignments; they were obsessions. I care about how things work at the lowest level because that's where the interesting problems live.
The fastest way to get better at thinking is to solve problems under constraints. Competitive programming sharpens the same skills I use in production — breaking complex problems into smaller pieces, choosing the right data structure, and writing code that's correct on the first run.
I'm fascinated by what happens when you fine-tune foundation models for real-world domains — not toy demos, but systems that generate culturally accurate design patterns or pedagogically sound study material. The gap between "impressive demo" and "useful product" is where the real research happens.
I write code that runs, ship products that work, and think in systems.
— from my resume, because it's the truest thing I've written.
