AI engineer and full-stack architect building the systems between models, products, and teams.

Three chapters

Chapter 1 — Mobile games (2014 — 2018)

Casual, hypercasual, cooking — including titles like Masala Express. Where I learned to ship: app-store discipline, live-ops, the weight of a single bad review on a 4-star app. Mobile games taught me that the player’s experience is the product, not the code.

Chapter 2 — Multiplayer systems (2018 — 2023)

Real-money games (Ludo, cards) and then the multiplayer framework work at Frolic. Distributed systems by the back door — every concept I’d later use in AI platforms (idempotency, replay, observability, schema migration) showed up first in multiplayer infra. This is also where I learned to design abstractions other engineers consume.

Chapter 3 — AI / Full-Stack (2023 — present)

GlamAR at Fynd. Skin analysis, real-time face tracking, light detection, custom model training infrastructure. The frame finally clicked: AI is a systems problem with a model in the middle, not a model with a tiny system around it. Most of the engineering effort lives in the path to and from the model — pre-processing, eval, serving, recommendations downstream. That’s where I work.

Operating at senior scope

I work at the seams where product, research, and platform engineering meet. My job is to make the hard boundaries explicit: what a model promises, what a service guarantees, what a frontend can explain, and what the team can operate six months later.

Set technical direction

I turn ambiguous product goals into architecture, contracts, and a sequence of decisions a team can execute. The useful output is not a diagram; it is shared direction that lets several teams move without waiting on one person.

Create leverage through others

I design systems that make the next engineer faster, write down the why behind important choices, and treat mentorship and sponsorship as part of delivery. A senior engineer’s impact should compound after they leave the room.

Keep production honest

I care about the whole path from input to outcome: evals, failure modes, latency, cost, observability, and the product behavior around a model. A demo is a hypothesis; production is the proof.

How I work

Boundaries first. I spend a disproportionate amount of design time on contracts between layers — the place where one team hands work to another. Most failures I’ve seen in production systems were not bad code inside a layer; they were unclear assumptions across a layer boundary.

Eval before optimization. The first investment in any AI system is the evaluation harness. The second is the model. People do this in the wrong order more often than not, and pay for it for years.

Specialized over general, until proven otherwise. Multi-purpose systems sound good in design docs and are painful to operate. Specialized systems with sharp boundaries scale further than people give them credit for.

Document the why. Architecture diagrams age poorly. The reasoning behind them ages perfectly. I leave the why in the repo, not the meeting where the decision was made.