About
How I operate
Most of the companies I work with have the same presenting symptom: things are scaling and things are breaking, and nobody in the building agrees on which things are which.
My job starts before the fixing. It starts with sitting in the ambiguity long enough to find the structural problem underneath the symptoms everyone's been debating. That's the discipline I've built over twenty years and five companies: resist the urge to solve, define the problem with precision, then build the team and the operating system to make it durable. The companies have ranged from a startup I co-founded to a 60-person engineering organization to a Big Five bank. The pattern hasn't changed. Traction is real. Systems are fragile. Connect the two before the gap becomes fatal.
Along the way, I've learned that the most valuable thing I bring into a room is often that I wasn't in the room before. I tend to take on problems in domains that aren't my background, invest deeply to understand the terrain, and find the structural issues that insiders have learned to work around. Fresh eyes, applied with operating experience, tend to see what familiarity has made invisible.
Give me an inch of responsibility and I'll turn it into a mile of ownership. That part I can't seem to help.
Get the condensed version
If you want the traditional format before reading further, share your details and get my current resume.
The short version
I've spent 20+ years doing one thing in different contexts: walking into companies where the traction is real but the systems are fragile, and installing the engineering, operational, and financial infrastructure that makes growth durable.
That's it. That's the whole thing.
The companies change. The industries change. The tech stacks change. (Remember when everyone needed a Flash developer? I was that guy. In Bangkok, no less.) But the pattern stays the same. Something is working. Something is also breaking. And nobody has connected the systems that would let the working part scale without the breaking part getting worse.
I fix the connection.
What I actually do is connect the systems that scaling SaaS companies treat as separate: engineering execution, go-to-market infrastructure, financial controls, and data/AI readiness. Most advisors own one lane. I wire them together so the company can grow without the founder being the single point of failure for every decision.
The pattern
Every company I've worked with, whether I co-founded it, led the engineering org, or walked in as an advisor, has followed the same arc. The specifics are different. The structure of the problem never is.
The Durable Growth Arc
Diagnose
Find the structural weakness (not the symptom everyone is complaining about)
Install cadence
OKRs, planning rhythm, delivery metrics, ownership clarity
Align to revenue
Wire engineering output to business outcomes
Modernize the platform
Cloud-native, event-driven, integration-ready
Strengthen governance
Compliance, security, risk controls that unlock markets
Stabilize cash
R&D credits, capital efficiency, runway awareness
Scale durably
Growth that doesn’t collapse when you double
If you're thinking “that sounds obvious,” you're right. It is obvious. It's also almost never done in order, and half of it gets skipped entirely because everyone wants to jump straight to the modernize step. (“Let's rebuild the platform!” No. Let's figure out why you're rebuilding it first.)
The reason this works is boring: it's sequential, it's disciplined, and it treats the company as a system rather than a collection of departments with separate Jira boards.
Where I've done this
I don't have a “typical” career path. I've co-founded companies, led 60-person engineering orgs at Deloitte Fast 500 firms, run digital innovation at a Big Five bank, and spent my first eight years building enterprise software in Bangkok and Toronto. The thread that connects all of it is the pattern above. In every case, I walked into a domain that wasn't my background, invested deeply to understand it with fresh eyes, and found the problems that everyone else had stopped noticing. Here's how it played out:
An AI-powered EdTech SaaS
Joined as Head of Engineering. Got promoted to COO six months later because the company needed an operator, not just an engineering lead. (This happens to me a lot. I should probably put “will inevitably end up running operations” on my business card.)
The company had a great product and loyal teachers. It did not have an enterprise sales motion, a CRM that anyone trusted, a compliance posture that could survive a district IT review, or a clear picture of its own cash position. The engineering team was talented but disconnected from revenue.
What we installed: RevOps from zero (HubSpot, Apollo, pipeline segmentation, closed-lost recovery across 193 deals). Enterprise integration posture (OneRoster, Clever, SSO, API security). An activation-led GTM engine that hit 91 to 98% license activation in a market where 65% is considered good. Financial controls that identified a cash runway problem five months earlier than the existing forecasts suggested. R&D tax credit optimization that captured ~$600K/year.
On the AI and platform side: led the architecture pivot to cloud-native microservices on AWS. Directed $2M+ in R&D across ML-based reading assessment and adaptive learning systems. Integrated LLM and TTS systems (evaluated and deployed across OpenAI, ElevenLabs, and Azure Neural providers) into product and internal workflows, building the data infrastructure to support them at scale.
114% ARR growth. A company that went from founder-led to enterprise-ready.
A global EdTech platform (Exited 2022)
Co-founded this one. Built it from literally nothing to 5.8M users across 119 countries and 14,400 schools. Full P&L ownership through 35 major product iterations over seven years.
This is where I learned that building the product is maybe 30% of the job. The other 70% is building the company around the product: the team, the architecture that scales without falling over, the data science practice that didn’t exist before we built it, the compliance posture (GDPR, CCPA) that lets you operate globally. I served as Data Protection Officer because at a startup, you wear every hat, including the one that keeps you out of regulatory trouble. That experience shaped how I think about security and governance: not as a late-stage checkbox, but as infrastructure that opens markets and shortens sales cycles. And the partner integrations that turn a product into a platform.
We migrated from a monolith to Kubernetes-based microservices. We built a Partner API platform.
Guided the company to a successful acquisition in 2022. The exit was the outcome. The system we built was the product.
Enterprise and institutional scale
Before the startup years, I led engineering and digital transformation at larger organizations. 60+ engineers at a Deloitte Fast 500 assessment technology company scaling toward $24M ARR, where I drove post-acquisition integration and restructured the engineering org. A 50-person cross-functional innovation team at BMO Financial Group, where a personalized digital sales system drove a 35% sales increase in six months. Eight years on a founding team in Bangkok and Toronto building enterprise process management systems from the ground up.
These roles taught me how larger systems work, how post-acquisition integrations succeed (and fail), and how to install operating discipline across complex organizations. That experience is what I bring back into smaller, faster-moving companies where it has the most leverage.
The personal bit
Based in Toronto. Building remotely. Originally from India, via Bangkok, which means I've had strong opinions about both food and timezones for most of my adult life.
Before I co-founded my first company, I spent six months surveying 1,000 K-12 educators across Canada and the United States, with 400 video interviews, trying to understand how technology actually gets used in schools. That research obsession never went away. I still believe the best technology decisions start with understanding the humans who have to live with them.
I'm a member of TrueNorthCTO (a community of 1,000+ Canadian technology leaders) and the Toronto Machine Learning Society, mostly because I enjoy being around people who argue about architecture decisions for fun.
Working together
Through my advisory practice, Peepul Tree Products, I work with SaaS founders between $500K and $5M ARR who've proven the product works but can't get the go-to-market, engineering, data, or operating systems to keep pace. The work usually looks like fractional CTO leadership, GTM engineering, or operational transformation, depending on what's actually broken. My advisory practice operates as Peepul Tree Products.
If that sounds like your situation, there's a page for that.