AAA
View All Tags
First GenAI hire brought in to architect and scale the enterprise GenAI program, partnered with product leadership to launch 7 product lines and deliver $4.8M in annual operational savings. Architected & scaled the flagship roadside assistance platform from 0 to 1, serving 60K+ DAUs, and driving a 44% increase in accuracy across AI-powered interactions.
When most developers see tickets on an agile board, they see tasks. I see leverage, often starting from point -1.
Our company had dozens of digital properties: membership portals, insurance dashboards, travel booking engines, branch locators. Each operated as its own kingdom: different stacks, teams, release cycles, and definitions of “urgent.
Every new capability required negotiating entry into each one. This is the kind of friction that masquerades as process in high-bureaucracy environments: discovery calls, integration debates, version mismatches, bandwidth constraints.
A simple feature, like a universal point of ingestion to our generative AI roadside assistant, turned into months of coordination. One property would launch. The rest would wait.
I realized we were building a product that required adoption.
The problem was territorial.
I built the platform to behave like a parasite. Without asking for permission or negotiating entry, it attaches itself where traffic already exists and begins operating within the host, without requiring the host to change.
Technically, this meant a single script that:
Handling session context across properties without direct integration required reconstructing user state from fragmented signals—cookies, local storage, URL parameters—and resolving them via backend identity mapping, all without relying on host-provided authentication hooks.
This model prioritizes survival and sacrifices flexibility.
It also required strong guardrails to avoid interfering with host behavior.
But in early-stage systems—especially in uncertain domains like GenAI—distribution is the primary constraint. Removing friction mattered more than enabling control.
This reduced integration from a multi-week process to a ~30-second decision.
Over the next six months, the assistant appeared on over most properties.
There were no integration meetings, no onboarding docs, and almost no support requests. Teams adopted it independently because the cost to try was negligible and rollback was trivial.
"Add this script tag."
"That's it?"
"That's it."
What normally takes weeks of coordination became a same-day decision. Adoption worked because the value was immediately visible to end-users.
This simplicity was deliberate. Descoping became the core design tool. Every configuration option, like theming or customization, was a potential bottleneck disguised as flexibility. So it was removed.
All updates shipped centrally and became instantly available everywhere, without requiring any action from host teams.
The system knew how to find what it needed. The host didn’t need to know anything.
A platform requires upfront investment but compounds in value through adoption. Its scalability is determined by how easily it propagates.
Most platforms behave like guests: waiting to be invited, configured, and maintained. They fail when they require effort to adopt.
This one behaved differently. It attached itself, adapted quietly, and delivered value unobtrusively.
If you want something to spread across an organization, don’t optimize for configurability. Optimize for inevitability.
The most effective systems don’t demand adoption. They make it unavoidable.
That’s the kind of leverage I aim for, that is, build once, and remove the need for others to build at all.