About
Measure first. Ship the smallest thing that moves the number. Prove it moved.
Senior Software Engineer · 7 years · Gurugram, India
Background
I'm a senior software engineer with seven years of building web applications that people use to do their jobs — not demos. Most of that time has been spent somewhere in the TypeScript, React, Next.js and Node stack, with enough time on the backend and infrastructure side that I'm comfortable owning a feature from the database schema to the focus ring.
I started at Paytm Payments Bank, building internal tools for around 1,500 branch staff working on networks that made every kilobyte count. That's where I learned that performance is a user-facing feature and that data integrity bugs are the ones that cost you sleep. At Jio I moved between a React front end, a Node BFF and Python services on Azure, and spent a lot of time on the seams between them — including a long hunt for intermittent 504s that ended with correlation IDs and keep-alive tuning.
At Trajector I architected a Message Center that unified communications across three portals and three lines of business on a shared database. It now carries around 10,000 messages a day for roughly 6,000 daily users and has taken about a thousand support hours a month out of phone and email queues. It's the piece of work I'd most want to be asked about.
Right now I'm building in the direction I find most interesting: retrieval systems and event-driven backends. That means a RAG stack on Postgres and pgvector, and a chat service modelled twice — once through a RabbitMQ broker and once as a gRPC contract — to understand the tradeoff properly rather than from a blog post.
I keep a rule for my own résumé: if an interviewer could corner me on a line in two minutes, either I build it this week or I cut it today. The same rule applies to this site.

Education
B.Tech, Computer Science & Engineering
Graphic Era University · Dehradun, India
How I work
Three things I'm actually hired for.
01
Measure, then move
I don't ship performance work on a hunch. Correlation IDs, OpenTelemetry spans and structured logs come first, because the fix is usually obvious once the trace is readable. The 504s I chased across a React → Node → Django chain took weeks to find and an afternoon to fix.
02
Fast where it's hard
Most of my users have been on constrained networks and older hardware — branch bank staff, not engineers on fibre. That makes payload size, compression and interactivity real constraints rather than lighthouse-score vanity, and it's why the UIs I build stay responsive and accessible by default.
03
Comfortable at the seams
Message brokers, gRPC contracts, serverless functions, vector indexes — the parts where one system hands work to another. I like this layer because it's where architecture decisions become visible, and where a wrong one gets expensive quietly.
Stack
What I reach for.
Frontend
- TypeScript
- React
- Next.js
- App Router / RSC
- Server Actions
- Tailwind CSS
- Web Vitals
- Accessible UI
Backend
- Node.js
- Express
- REST APIs
- gRPC / Protobuf
- RabbitMQ
- AWS Lambda
- Django
- Event-driven services
Data
- PostgreSQL
- pgvector
- MongoDB
- Mongoose
- Drizzle ORM
- Schema & index design
Platform
- Docker
- Azure Functions
- GitHub Actions
- OpenTelemetry
- Structured logging
- Correlation IDs
AI / LLM
- RAG pipelines
- Embeddings
- Top-K vector retrieval
- HNSW
- Prompt grounding
- Ollama
Open to work
Want the longer version?
Most of what's above compresses down to a few decisions I'd happily talk through — the Message Center architecture, the 504 hunt, or why the retrieval layer is where a RAG system lives or dies.