The most dangerous gap in any organization is between the people who understand the business and the people who build the systems.
I’ve spent 20 years trying to be the person who closes that gap. I didn’t plan to become a person who builds technology. It happened slowly, and then all at once.
In 2009, two years into my stint at Kotak’s Private Equity arm, the group’s alternate assets platform was scaling — multiple funds across residential, commercial, and affordable housing — and it needed a unified CRM to manage investor relationships across them. Siebel was being implemented at the group level, and I volunteered to lead it for our division.
Not because I was a tech person — I was a CA with an MBA — but because I could see the problem clearly and I was impatient enough to want to fix it myself. That project taught me something I’ve carried for 20 years: the person who understands both the business problem and the technology has an unfair advantage.
Around the same time, I designed and built our investor reporting portal — a single place where investors could access fund communications, past documents, performance updates, and NAV, all in one interface. Information dissemination became instantaneous instead of waiting for mailers to go out. It wasn’t revolutionary technology — but in the PE world, it was unusual for the finance team to build the tool instead of requesting it from IT.
The DivyaSree Years: ERP and Organizational Rewiring
When I moved to DivyaSree in 2018 as VP Finance (CFO level), I took charge of six departments — Finance, Taxation, Legal, Secretarial, Compliance, IT, and HR. I led the ERP implementation —working across six departments to drive adoption and change management. If you’ve never been through an enterprise ERP implementation, here’s what they don’t tell you: the technology is the easy part. The hard part is getting a 500-person organization to adopt new workflows — more persuasion than any term sheet negotiation I’ve done.
We also started mentoring our PropTech portfolio companies on strategy and tech adoption. Sitting across the table from founders building real estate technology while simultaneously raising a $200 million fund from a sovereign wealth fund gave me a perspective few people get — I could see both sides of the build-versus-buy equation.
The AI Chapter
By 2023, large language models had gone from research papers to production tools. I saw the opportunity and, more importantly, I saw the constraint. In real estate and finance, your documents contain the most sensitive information your organization possesses — land records, board resolutions, investor agreements, deal structures. Sending any of this to a cloud API was out of the question.
So I built a proof of concept for on-premise AI — a private RAG (Retrieval Augmented Generation) system that lets you ask questions about your own documents and get sourced answers, with text-to-speech and speech-to-text layered in, without a single byte leaving company servers. We ran it on high-end workstations used by the architectural design team — no new hardware budget required.
The proof of concept worked. It validated that on-premise AI could handle real enterprise workflows — private document Q&A, voice interfaces — without touching the cloud. Building it taught me more about AI’s real capabilities and constraints than any amount of reading or vendor demos ever could. That conviction hasn’t left.
The Home Lab: Where I Learn by Breaking Things
Somewhere along the way, I started building at home too. Part of the motivation was straightforward: I wanted my family’s data off Google’s network — no GDrive, no Google Photos, no dependence on someone else’s infrastructure. What began as a simple NAS (network attached storage) for family backups evolved into a full enterprise-grade infrastructure: Gentoo Linux compiled from source, 30+ Docker containers, an SSO stack (LDAP → Authentik) that my family unknowingly uses every day, Prometheus and Grafana for monitoring, automated backups with BackupPC, DNS-level security with AdGuard and Unbound, and AI inference running on llama.cpp — compiled from source, using ROCm on an AMD 780M iGPU with GTT memory to load models into the full 64GB of system RAM.
I bought the Ryzen 8700G with 64GB RAM about two years ago, shortly after launch. My thesis was simple: the iGPU sits on the same memory bus as system RAM. There’s no physical barrier — unlike a discrete GPU, no data needs to move across a PCIe bus. The BIOS VRAM allocation is an artificial limit, not an architectural one. I researched it, found that people had cracked GTT memory access, got ROCm working on the 780M, and proved the thesis. That single hardware bet — based on reasoning about memory architecture, not waiting for benchmarks — is what lets me run serious AI workloads at home today.
Why Gentoo, and why compile llama.cpp from source instead of using a packaged solution? Because building from source teaches you what every layer of the stack actually does. It’s the same reason I pursued an LLB while working full-time at Kotak — I wanted to understand the legal machinery behind the documents I was negotiating, not just the commercial terms.
People sometimes ask why a finance professional runs this kind of setup at home. The answer is simple: I can’t evaluate technology I haven’t built. I can’t make AI strategy decisions if I don’t know what a context window is, how retrieval actually works, or why a 3-billion parameter model sometimes outperforms a 14-billion one for specific tasks.
The thread connecting all of this isn’t technology for its own sake. It’s a belief that the most dangerous gap in any organization is between the people who understand the business and the people who build the systems. When one person can bridge that gap, things move faster, cost less, and actually get adopted.
I’m a chartered accountant who compiles his own operating system. A fund raiser who runs Docker containers. A deal structurer who orchestrates language models. None of these identities contradict each other. They compound.