I ship the enrolment system behind 1M+ people's health cover.
This is the log.
Four years, one team, reverse order. Each entry is a change that reached production, with the number it moved.
Shipping log
performance
Login page rebuilt for slow networks
- load
- 4.5 s→1.5 s
- initial JavaScript
- 3.3 MB→230 KB
- Lighthouse
- 60→90
How it was done
Problem
The portal’s login page shipped 3.3 MB of JavaScript before a member could type a phone number — the whole app, a Firestore SDK used for one timestamp, and a component library imported whole. On slow 4G that was 26 seconds.
Decision
Measure first, then remove: instrument the page, then code-split by route, lazy-load the animation and date-picker chunks, drop the Firestore SDK for one line of arithmetic, self-host the font with a preload, and land tree-shaking in the shared component library so every consumer imports only what it renders.
Result
Login load time fell 67% (4.5 s to 1.5 s; 26 s to 6 s on slow 4G). Initial JavaScript fell 93% (3.3 MB to 230 KB). Lighthouse Performance went from 60 to 90. Total shipped JavaScript across the portal fell 54%.
platform
Production deploys, and the keys that ran them
- deploy
- 10 min→< 1 min
Parallel jobs, partial-clone checkouts, pinned toolchain, Slack release reporting. Long-lived service-account keys replaced with keyless Workload Identity Federation.
platform
A usable link for every pull request
- commit to product link
- days→< 60 s
How it was done
Problem
A change was “done” when it merged, but nobody outside engineering could use it until it reached a shared staging environment — often days later. Design waited to review, QA waited to test, product waited to check copy. Every round of feedback restarted the wait.
Decision
Give every pull request its own deployed instance, reachable at a stable URL that updates on each commit. Only the changed app is built; unchanged services route to shared staging behind a gateway, so a frontend PR does not need its own backend. Idle instances stop after a few minutes and wake on the next request.
Result
Commit-to-usable-link time went from days to under 60 seconds. Reviewers open the PR link instead of asking for a deploy. The system was later written up by engineering leadership as a team-wide practice.
reliability
Observability from zero
- frontend MTTR
- 2 days→< 1 hour
- custom RUM vitals
- 21
How it was done
Problem
Frontend failures surfaced when a customer wrote in. There was no way to tell a real regression from an expected validation error, no per-release view, and nothing that paged anyone.
Decision
Instrument the journeys that matter — checkout, dashboard load, login — as 21 named duration vitals, and record expected outcomes (a wrong OTP, a known 4xx) as actions rather than errors, so the error stream only carries surprises. Build one dashboard around it: p95 latency and error rate by endpoint, Core Web Vitals by route, errors per session by release. Wire alerting to the parts that page.
Result
Mean time to resolve frontend incidents went from about two days to under an hour. Escalations went from routine to rare, and every release now has a before/after view within minutes of deploy.
correctness
Checkout made replay-safe
A race between async benefit writes and confirmation could wipe a member’s benefits. Modelled as guarded state transitions; every step idempotent.
How it was done
Problem
Enrolment checkout wrote a member’s chosen benefits asynchronously while a separate confirmation step marked the member enrolled. Under the wrong timing — a retry, a double submit, a slow write — an empty checkout could land after a full one, wipe the benefits, and still mark the member enrolled. In health insurance that is someone’s coverage.
Decision
Model checkout as explicit states with guarded transitions. A confirmation cannot advance from a state that has no persisted selection; a write that would replace a non-empty selection with an empty one is rejected; and every step is idempotent, so a replayed request produces the same end state as the first.
Result
The failure mode became impossible rather than unlikely. Support escalations for “enrolled but no benefits” stopped, and the same guards now protect every new purchase flow added to the portal.
developer experience
Tree-shaking in the shared component library; MCP for the codebase
- shipped JavaScript, portal
- 4.6 MB→2.1 MB
Five library PRs every client app now imports from. An internal Model Context Protocol integration streams live browser UX context into AI coding agents; repo agent rules keep AI-assisted changes on team conventions.
platform
Runtimes off end-of-life
- HR dashboard
- Node 14→Node 18
- enrolment portal
- Node 18→Node 24
role
Promoted to Software Development Engineer II
Intern to SDE-2 in 24 months. Leading 1 SDE and 1 intern; 1,000+ pull requests reviewed across 8 repositories.
performance
Operations view that renders 20,000 members at once
- heap
- 2 GB→40 MB
Table and row virtualization. Usable on low-end operator machines.
backend
HR registration hardened at ingest
- backend PRs
- 8
Mobile, name and currency sanitisation; cross-policy duplicate-credential detection; coverage and salary backfill; hard delete on mid-term rejection.
role
Software Engineer. Shipped the benefits selection portal
- first production version
- 10 days
Became the foundation of the corporate enrolment platform. Custom IdP SSO and email-OTP login followed.
quality
HR dashboard ported from JavaScript to TypeScript
- files in TypeScript
- 619 / 621
Alongside: adoption from 20% to a 100% rollout; bulk policy amendments from 1 to 5 batches a day.
role
Joined Loop Health as a Software Engineer Intern
Built 10+ components in the shared React library.
role
Contract at Caliber, Missouri (remote)
Challenge lifecycle, Firebase Auth SSO, Google Fit integration. React, Material UI, Spring Boot. Async across a 10.5-hour offset.
role
First role: The Innovative Solutions, Pune
Two government-funded platforms: role-based access, document verification, PayU payments, Express and MongoDB.
Skills
- Core
- TypeScript, JavaScript, React 18, Redux Toolkit, React Query, TanStack Table, React Native, Node.js, Java, SQL
- Backend
- Node.js microservices, Express.js, Spring Boot, REST APIs, GraphQL, system design, authentication, Single Sign-On (SSO), OAuth 2.0, JSON Web Tokens (JWT), Identity Provider (IdP) integration, PostgreSQL, MongoDB
- Cloud
- Google Cloud Platform (GCP), Cloud Run, API Gateway, Cloud Load Balancing, load balancing, Firebase, Docker
- Platform and delivery
- GitHub Actions, CI/CD, pull-request preview environments, Workload Identity Federation (WIF), Vite, build optimization, web performance, feature flags, Flagsmith, Agile/Scrum
- Reliability and security
- Datadog RUM, Datadog dashboards, custom vitals, on-call alerting, Sentry, Core Web Vitals, unit testing, integration testing, Jest, Vitest, Playwright, Content Security Policy (CSP), SOC 2, penetration testing, VAPT remediation
- AI engineering
- prompt engineering, Model Context Protocol (MCP), LLM coding agents, agent-rule and repository-context authoring, Claude Code, GitHub Copilot, Cursor
Outside work
psyMing — An offline-first PWA for habits, reminders and milestones, with web push driven by a cron scheduler. Built because every habit app I tried needed a network connection to tell me to drink water.
speaktype — Fixed the control pill and menu-bar panel so they render over full-screen apps, in a 100% offline open-source voice-dictation app.