An engineer who treats boring as a compliment
I'm an engineering lead and DevOps engineer with 4.5+ years operating production cloud infrastructure on AWS and Azure. I cut cloud bills, migrate clusters, and ship backend services that don't page me at 3 AM.
I started writing code at PCCOE in Pune, finished my Bachelor's in Computer Engineering in 2020, and joined CareerLabs as a Product Associate. Within a year I was full-time on the backend, shipping a URL shortener that the marketing team still uses.
The pivot to DevOps was accidental. Our staging environment was a single EC2 instance maintained by a developer who'd just resigned. Someone needed to take it over. I volunteered, mostly because I wanted to learn what was in there. Within six months I'd Terraformed it, cut the bill 40%, and accidentally become "the cloud guy".
What I'm actually good at
Running production on AWS and Azure, finding 30–40% in wasted spend, migrating clusters without page-outs, and writing Node services that don't take down their own databases. I'm best when the problem is "this is on fire" or "this costs too much" — less interesting when it's "make this prettier".
What I'm not
I'm not a frontend designer. I can ship a passable Next.js UI for my own SaaS, and I get out of the way as soon as someone better takes over. I'm also not a greenfield architect — I do my best work on systems that already exist and have problems I can measure.
Boring infrastructure
Novelty is the enemy of uptime. I reach for the well-understood thing — Postgres, EKS, Terraform — before the new thing, every time.
Cost is a feature
A 40% bill reduction is the same as a 40% revenue increase, and easier to ship. I treat cost like latency: measure it, budget it, alert on regressions.
Write things down
Runbooks, ADRs, postmortems. Future-me forgets and future-team is hired after the fact. The notes are the system.
Small blast radius
Per-env clusters, namespace RBAC, least-privilege IAM. When something breaks — and it will — it should break in one place, loudly.
I read more infrastructure postmortems than is probably healthy, and I'm slowly working through "Designing Data-Intensive Applications" for the third time. On weekends I either ship a tiny tool — the latest being a Meeting Analyzer for Google Meet — or completely log off.
I'm based in Ahmedabad and work on-site at Confiance. I'm not actively looking, but I'm always happy to talk about cloud cost, Kubernetes, or whether your team should self-host its own monitoring (the answer is usually yes).
Bachelor of Engineering — Computer Engineering, PCCOE / University of Pune, Sep 2016 – Oct 2020.