How I think about this
Five things I believe about AI, enterprise organizations, and what it actually takes to build something useful.
Most AI projects don't fail. They stall.
The readiness gap. Good ideas arrive before anyone inside a large organization is ready to say yes to them. By the time approval lands, someone outside has already shipped it. The gap isn't technical — it's organizational. The people closest to the problem rarely control the budget to solve it, and the people with the budget are too far from the problem to feel its urgency. I spent a decade inside that gap. Closing it from the inside is harder than building the thing, and more valuable.
Operational innovation vs. innovation theater.
A strategy deck about AI transformation is not AI transformation. A bot that actually runs the morning brief is. The difference is whether anything about how people work changes on a Tuesday at 9am. Most AI initiatives are theater: visible, well-branded, and unable to survive contact with daily operations. The ones that survive are the ones nobody asked for permission to build — because they were too small to require a committee, and too useful to kill once they were running.
The human must confirm.
Every system I build has the same invariant at its center: the AI classifies, drafts, suggests, routes — and the human approves. Not because AI gets it wrong. Because the cost of silent error in financial data, task records, and communications is asymmetric. An extra tap costs a second. A silent error costs an audit. This isn't skepticism about AI — it's good systems design. The confirmation step is what makes automation trustworthy, and trustworthy is what makes it actually used.
Build the embarrassing version first.
The right size for a first version is smaller than you think. Not a pilot. Not a proof of concept with a steering committee. A version so specific it's embarrassing to explain — built for one person, for one problem, in one week. That specificity is what makes it work. The generalized version — the one designed for many people and approved by a committee — is the one that fails quietly. Start with the one you'd be shy to demo. That's the one that will teach you something.
Deliver where people already are.
A new app is a new habit. A new habit is friction. Every system I build delivers its output in a channel people already have open: Telegram, email, the tool they're already holding. Not a dashboard they'll check once, not a portal they'll bookmark and forget. The product is the output, not the interface. If someone has to change their behavior to receive the value, the value probably won't reach them.
The ideas above are tested in the work below.
See the work →