I build systems that survive contact with reality.
I've been building software for 10+ years. It started with client projects I took on while I was still at university - real deadlines, real people depending on the result - and most of the time since has been spent on founding teams, where the title matters less than the fact that if you don't decide something, nobody does.
Right now I'm a Senior Product Engineer on the founding team at Sully.ai, working on tooling that takes administrative load off doctors - a domain where being roughly right is not a category of answer.
I sit on the engineering advisory board there and work directly with the CTO, which in practice means owning the architecture decisions early enough that they're still cheap, and being the person accountable when they turn out to be wrong. Before that I was on the founding team at CloudFiles, and I've run Impactful Labs since 2018.
The thread through all of it is the unglamorous half of engineering: performance budgets, type systems, error tracking, the migration nobody wants to schedule. That work is what makes a product hold up once people depend on it, and it's the part I've made my job.
How I work
Measure it, then claim it
I'd rather say 800ms than 'faster'. Numbers force honesty about whether a change actually worked, and they make it obvious when it didn't - which is the more useful half.
Boring technology, deliberately chosen
Most projects fail on maintenance, not on capability. I reach for the stable, well-documented option unless there is a specific reason not to, and I want to be able to state that reason out loud.
Fix the cause, not the symptom
Migrating to TypeScript cut production bugs by a quarter - not because types are fashionable, but because the same class of bug kept coming back and patching each one individually was never going to end.
Decide early, while it is still cheap
Architecture is mostly a question of which decisions you can afford to defer. The ones you cannot are worth arguing about properly, in the first week, with the people who will live with the answer.
Ambiguity is the job
On a small team the requirements are usually a sentence and a deadline. Turning that into something specific enough to build - and being willing to be wrong in public about it - is most of the work.
Build for whoever inherits it
On a small team you are usually the person who inherits your own work six months later. Tests, types and readable structure are a favour to your future self before they're anything else.
How I got here
Sully.ai
Senior Product Engineer, Founding Team
Mar 2024 - Present
Impactful Labs
Founder
Jun 2018 - Present
CloudFiles
Senior Product Engineer, Founding Team
Jan 2022 - Feb 2024
M. R. Gangani & Bros
IT Automation Engineer
Jan 2020 - Dec 2020
White Graphics
Web Development Intern
Oct 2019 - Dec 2019
A few other things
- Started Impactful Labs at 20, and still run it.
- Endurance athlete. The long-ride mindset maps onto shipping software better than it has any right to.
- Have written production code in six languages, and still think the hard part is deciding what to build.
- Based in Mumbai, and most of the photographs on this site were taken somewhere between here and Kerala.
Get in touch
If any of this resonates, or you want to argue with it, I'm happy to talk. Email is the easiest way to reach me; the calendar link is there if you'd rather just book the time.
Prefer the formal version? Download my resume.