"I don't really care which language you use."
What I care about: that the system survives its second year. That the team who inherits it can reason about it at 2 AM. That we shipped on time and didn't create a problem that takes three engineers six months to untangle.
The interesting problems are almost never about the technology. They're about constraints, tradeoffs, and the people who have to live with the decisions you make.
Numbers That Matter
Real results,
not estimates.
Years building software
Across startups, agencies, and enterprise systems
Engineers mentored
Through architecture discussions, code reviews, and career growth
Drop in transaction times
Flipkart Health Plus API redesign
More bugs caught pre-production
Automated validation framework for NVIDIA
Increase in user growth
Taxspanner platform modernization
How I Approach Engineering
Six things I actually believe.
Start with the problem, not the stack
The framework you pick rarely makes or breaks a project. What actually matters is understanding your real constraints early on. I have watched teams succeed with Node, Python, and PHP, and I have seen them fail with all three when they solved the wrong problem.
Make complexity earn its place
Every extra layer is a cost someone on your team will have to pay later. A queue makes sense when you need async processing, not because it looks good in an architecture diagram. Add moving parts only when the problem leaves you no choice.
Code is read much more often than it is written
Write code for the person who has to debug an issue at 2 AM. That means straightforward naming, honest comments when something is tricky, and error messages that explain what broke instead of failing silently.
Speed is part of user trust
Dropping latency from 3.5 seconds down to 500 milliseconds is not just a tidy benchmark. It stops users from bouncing and getting frustrated. Measure before you guess, and fix the actual bottlenecks.
Leave teams stronger than you found them
Repositories get rewritten, but good engineering habits stick around. The most rewarding part of any lead role is helping team members build the skills and confidence to solve hard problems on their own.
Migrations are careful surgery, not quick tasks
Upgrading a live financial system from Python 2.7 to modern Python without downtime takes patience. You have to plan for failures, route traffic gradually, and verify every step along the way. Small incremental rollouts beat all-at-once cutovers every single time.
Work That Shaped How I Think
Four problems worth reading about.
Career
Where I've worked,
and what I built there.
Technical Notes & Writing
Practical engineering notes from nine years in the field.
Beyond the Code
The person
behind the PRs.
I am a lead software engineer based in New Delhi. Over the last nine years, I have worked on web applications and distributed systems for early-stage startups and larger companies like NVIDIA and Flipkart.
I began as a full-stack engineer building student portals and recruitment sites. Over time, my focus shifted toward backend architecture, database performance, legacy migrations without downtime, and helping engineering teams work well together. At Prismberry, I split my time between technical design and implementation for our clients, while mentoring engineers and refining our development workflows.
I do not believe framework debates are all that important. What really matters is understanding the problem and its constraints clearly enough that the right technical choice becomes obvious.
Lightning Round
Mac or Linux?
Linux all the way
Tabs or spaces?
Tabs, Indentation Matters.
Monolith or microservices?
Monolith until you actually need separate services.
Coffee or tea?
Strong tea, But let me make it
Editor?
VS Code, and Vim when I am in a terminal.
Debugging style?
Logging first, then the debugger, never guesswork.
Best part of engineering?
Seeing an engineer you helped guide solve a tough challenge on their own.
Biggest pet peeve?
A one-hour meeting that could have been a short README.
Currently Exploring
What I'm focused on now.
Updated August 2026
Building
- •A Python test and benchmarking framework for validating NVIDIA hardware configurations.
- •Lightweight telemetry collectors to make distributed backend debugging simpler.
Exploring
- •Practical LLM evaluation techniques to verify if model prompts are genuinely improving on specific tasks.
- •Where AI code review tools save time versus where they introduce silent blind spots.
Reading
- •Designing Data-Intensive Applications by Martin Kleppmann (re-reading it with a few years of production scars makes it hit differently).
- •The Staff Engineer's Path by Tanya Reilly, a grounded look at senior technical leadership.
Thinking About
- •Balancing hands-on architecture work with giving senior engineers the room to own technical outcomes.
- •Writing clear engineering notes that explain the tradeoffs we made, rather than just the final success.