What I've learned building AI products

Across the products I've built and the engagements I've led, the same lessons keep surfacing — usually the hard way. None of them are about models. All of them are about everything around the model, which is where the real work lives.

The demo is 10% of the work

A convincing prototype takes a fraction of the effort and creates the illusion that you're nearly done. The remaining 90% — reliability, evaluation, edge cases, security, the operating model — is the actual product. Setting that expectation early, with everyone, saves more pain than any technical decision.

Boring beats clever

Given a choice between a clever architecture and a boring one that's easier to operate and reason about, I now pick boring almost every time. Cleverness is a tax you pay every day the system runs. The goal is software people can trust and maintain, not software that impresses other engineers.

Trust is the real product

Users don't adopt AI features that occasionally embarrass them. A system that's right 95% of the time but visibly honest about the other 5% beats one that's right 98% of the time and confidently wrong when it isn't. Citations, graceful “I don't know”s, and human approval where it counts aren't polish — they're the product.

Ship narrow, then widen

Every product I've seen succeed started absurdly narrow — one workflow, done properly — and earned the right to widen by proving value first. Every one I've seen struggle tried to be everything on day one. Range, in a personal life, is a superpower. In a first release, it's a liability.

If any of this resonates and you're in the thick of it, I'm happy to compare notes — the contact and booking links are on this site.