AtThe operator
About the OperatorAbout me
Product Engineer & UX Strategist · Founder & CPO, DumbMoney · New Delhi, India
I learn whatever I need to in order to build the thing I think should exist. That has meant frontend one week and a PRD the next, usually on the same product.
At MapMyIndia [Gtropy] I work on enterprise fleet and telematics platforms — the software that tells someone where two hundred thousand vehicles are, and, more usefully, which four of them need attention right now. My role there has been consistent across every project: build the frontend, own the UI and the UX, work across teams, and write the document that says what we are actually solving.
I also run Smaak.ux, a small product and design studio, which is where I learned that a brand and an interface are the same argument told at different resolutions.
The airframe
Holding · on approach
02 / 06Ali Azam Kazmi
Loadout Technical28
Loadout Design09
Loadout Product09
Impact
Bars are log-scaled for absolute counts and linear for percentage deltas. Outcome metrics for the two missions still in build are not yet measured and are not shown.
| Mission | Frontend | UI / UX | PRD | Cross-team |
|---|---|---|---|---|
| Technician Appactive | ||||
| Mappls Shop Admin & Automated Billingactive | ||||
| IOCL GeoRTD Pipelineactive | ||||
| Vahan Shaktishipped | ||||
| Intouchshipped | ||||
| Locate — Manufacturer Backendshipped | ||||
| Control Towershipped | ||||
| Indane Yatra Mitrashipped | ||||
| FASTag Platformshipped | ||||
| Hermesshipped | ||||
| Owned on | 9/10 | 6/10 | 2/10 | 6/10 |
Every dot is a literal match against that mission’s role line — nothing is claimed here that the report itself does not say.
05 / Operating loop
What the role actually is
Across every project the shape is the same: I own the frontend, I own the UI/UX, I work across teams, and I end up writing the PRD — problem statement, user stories, acceptance criteria, the edge cases nobody wants to think about.
Not because the title says so. Because someone has to decide what matters first, and that decision is usually the one holding everything else up.
Find the decision nobody has made yet.
EvidenceMappls Shop Admin: billing was manual, and the real work was finding every place a human was quietly deciding.
Who feels it, what the system must insist on.
EvidenceTechnician App: installation, replacement and rectification are three different jobs wearing the same uniform.
Decide what matters first.
EvidenceVehicle status logic (moving, stopped, idle, delayed, offline) defined before anything was built.
Design for the hand, the signal and the daylight.
EvidenceMap UX: rotation, fit-to-route, route playback. Alarm, geofence and ticketing workflows.
The tool the problem needs, not the one on the résumé.
EvidenceReact, Angular, Ionic, RxJS, D3, Mappls SDK, and a 30,000-route geospatial pipeline into S3.
Own the frontend end to end.
EvidenceFrontend owned on nine of ten missions; UI/UX on six; the PRD on the active ones.
Live, in production, with real users on it.
Evidence5+ live projects. Vahan Shakti, Intouch and Indane Yatra Mitra on the Play Store.
Look at what happened. Then start again.
Evidence~40% dashboard speed-up, found after shipping, from caching, RxJS and API work.
Then the next problem
Smaak.ux · since 2023 · freelance
AtmosBrand identity
MintairInvestor pitch deck
RavenouxsResponsive website
Lean MultiverseBrand identity + web UI · 600K+ followers
EkalBrand identity, pitch decks
Urban LivinProduct catalogues
Sorted BlindsWebsite · Australia
Posh DikurMarketing creativesHow the work goes
Someone describes what is going wrong, in their own words and rarely in product terms. The job starts by taking that seriously rather than translating it too early.
Sit with the actual workflow — who touches it, where it breaks, and which parts are a person quietly compensating for the software.
Decide what is worth building and, more importantly, what is not. This is where the PRD gets written, and writing it is part of the role rather than someone else's handoff.
Design the thing against the real constraints: who is using it, on what, and under what pressure. Field tools and dashboards fail differently.
Choose the stack for the problem rather than for the CV — and stay close enough to it to know when a design decision has quietly become an engineering one.
Implement the frontend. Owning both the design and the code means the compromises get made deliberately instead of discovered at integration.
Get it in front of the people who described the problem, across whatever teams have to move for that to happen.
Find out what it actually changed, which is usually not the thing that was predicted — and that answer becomes the next problem.
Education
B.Tech, Computer Science Engineering
SRM Institute of Science and Technology, Chennai · CGPA 8.76 / 10.0
Leadership
Technical Convener, Directorate of Student Affairs · SRMIST
Directed Milan, a national cultural festival with 20,000+ attendees. Managed a 50+ member cross-functional team.
Vice President · Alexa Developers SRM
10+ technical events and hackathons. The flagship UI/UX workshop drew 300+ participants.
Capabilities