About
By day I help enterprises buy AI-led delivery. Before that I shipped regulated fund-accounting software at Temenos for three and a half years, with an MBA at IIT Kharagpur in between.
On paper that looks like three careers. In practice it is one question: is this worth building, and how do you know before you have built it?
In fund accounting the answer had to be provable. A wrong number cost a client money. A missed rule cost their trust. The MBA gave the question a language. Enterprise sales gave it the harshest test I have found: a buyer pays, or they do not.
Regulated finance: what being wrong costs
At Temenos I worked on a platform where being unforgiving about a wrong number was the requirement, not a slogan. I delivered the first client go-live on IBOR. HSBC. Forty-six funds into production, later past five hundred. The company gave me its GEM award for it.
What that work taught me is the discipline behind everything I build now. A number you cannot prove is a number you do not show. The gate on the dental ledger that stops an unverifiable figure reaching the dentist came straight out of that room.
Enterprise sales: what "worth it" means
I now sell AI-led delivery into enterprises. New business, end to end: qualifying, running discovery, shaping the proposal, structuring the commercials. It is the most direct read I have on which AI capabilities get funded and which ones stop at a pilot nobody renews.
That read settles arguments in my own work more often than any opinion I hold about product does. It decided where the paywall went in EaseMySemester, against an objection that sounded right at the time, and the reasoning is on the front page.
What the job trains is a specific kind of patience: nothing is real until somebody with a budget is willing to be wrong in public about it.
The proof
Somewhere in there I started building again, for people I know, where I could measure whether the thing worked. A ledger for a dental clinic. A question bank about fifty medical students use. A local search engine that runs on my own hardware.
Each one is a claim I can attach a number to. That is still the only way I can tell an idea from a product.
Working with people
I built the projects on this site alone; the day job is not in any sense. Qualifying an opportunity and shaping a proposal means losing arguments to delivery leads about what can actually be staffed, to pricing about what it costs, and to legal about what can be promised, before anything reaches a buyer. That is the part of my week that most resembles being on a product team, and it is the reason I do not think a spec survives first contact with the people who have to build it.
Clarity has two users and they want opposite things. A dentist I know wants the ledger to tell him about money. The attendant who books his day must never see a figure at all, so the rebuild is organised around the narrower of the two: she gets what she needs on her own request, and it has to die on the next request when it is revoked. Building for a second user whose requirements are mostly things she must not be able to do is the closest I get here to working inside a constraint somebody else set.
EaseMySemester is a batch of about fifty students who tell me a thing is wrong by quietly not using it. The navigation went back the way it came because I watched one of them try to reach a question the night before an exam, not because anyone filed a complaint.
The work behind that
- EaseMySemester10 min
- Clarity10 min
- Wiki Pipeline10 min
- Semantic Search6 min
- EaseMySemester v17 min
- The lab