“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
Three 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.
Based in New Delhi, my work as a Lead Software Engineer centers on designing resilient web applications and distributed backend systems. Over the past nine years, that journey has spanned high-growth startups as well as larger engineering environments like NVIDIA and Flipkart.
Early on, the work revolved around full-stack development, building student portals and recruitment platforms. Over time, that focus gravitated deeper into core backend architecture: tuning database performance, executing zero-downtime legacy migrations, and unblocking team bottlenecks. Today at Prismberry, days are split between technical architecture and hands-on delivery, paired with mentoring engineers and refining development workflows.
At this stage of my career, the greatest satisfaction comes from two things: architecting systems that remain quiet and dependable under heavy load, and seeing engineers on the team take ownership of complex technical challenges. Whether evaluating architecture trade-offs or untangling production bottlenecks, the focus is always on building software that lasts and helping teams move with clarity.
Lightning Round
Mac or Linux?
Linux all the way.
Tabs or spaces?
Tabs. Indentation matters.
Monolith or microservices?
Monolith first, until scale genuinely demands separate services.
Coffee or tea?
Strong tea, ideally homemade.
Editor?
VS Code for projects, Vim inside the terminal.
Debugging style?
Structured logs first, then the debugger. Never guesswork.
Best part of engineering?
Watching an engineer you mentored independently solve a complex system challenge.
Biggest pet peeve?
A one-hour meeting that could have been a three-line README.
Currently Exploring
What I'm focused on now.
Updated August 2026
- •A Python test and benchmarking framework for validating NVIDIA hardware configurations.
- •Lightweight telemetry collectors to make distributed backend debugging simpler.
- •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.
- •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.
- •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.