Most AI advice comes from strategists who have never shipped anything, or from engineers who have never sat with a customer. The gap between those two is where AI projects go to die. Side B exists in that gap.
Lead and senior product design roles at enterprise scale — global consulting, publishing, entertainment, and retail, including a product group I led design for. Much of the recent work has been on enterprise AI products: figuring out what one should actually do before anyone builds it. Formal training in business strategy on top of the design career.
That much of that work teaches you one thing above all — the technology is almost never what decides whether something succeeds. What decides it is whether anyone understood the actual job well enough to build the right thing.
So when AI agents arrived, I did the obvious thing for someone with that habit — I stopped writing about them and started building them. Not prototypes. A research agent that pulls SEC insider filings and options flow and scores conviction across dozens of stocks. A lead-generation agent that emails a sales team a fresh, qualified, deduplicated list every weekday morning, running in the cloud, without anybody's laptop being open. Both started the way good projects usually do: somebody asked could AI do this? and meant it as a real question.
Building those taught me things you cannot get from reading about AI. Where models are unreliable and what that costs. How much of the work is data and how little is the model. Why the second month is harder than the first. What "it works" actually means once real people depend on it at 8am on a Monday.
That combination is what you're hiring: design judgment about what's worth building, and enough engineering to build it — and to tell you honestly when it can't be built well. Same person, both halves. No handoff where the strategy meets the code and something quietly gets lost.
The A-side was the single. The one the label was confident about, the one engineered for radio. The B-side was where the interesting work happened — the track somebody made because they wanted to hear it, that turned out to be the one people kept.
AI right now is very loud on the A-side. Enormous claims, enormous budgets, and a lot of demos that never make it into anybody's actual Tuesday. The work that pays off is quieter: one process, done properly, running every day without anyone thinking about it.
That's the side I work on.
The most impressive available thing and the most valuable available thing are rarely the same thing. I start from what's costing you time or money right now and work backwards to the technology — sometimes arriving at something unglamorous that saves eight hours a week.
A demo proves something is possible. It doesn't prove it survives your real data, your edge cases, or the Thursday when the input arrives in a format nobody anticipated. I'd rather ship something narrow that runs than something broad that almost does.
Everything comes documented, with the reasoning written down and the code and prompts in your hands. If you'd rather take it in-house, or hand it to another developer, nothing about how I've built it should make that painful.
If AI isn't the right answer, if your data isn't ready, if the vendor is overselling — you'll hear it on the first call, not in week six. That costs me some engagements. It also means the ones I take tend to work.
Most AI failures aren't technical. Somebody didn't trust the output, or the handoff was unclear, or nobody knew what to do when it was wrong. Deciding where a person stays in the loop is a design problem, and it's usually the one that determines whether any of it gets used.
I take a limited number of engagements at a time. It's the only way the work gets real attention, and it's the reason I can be honest about scope instead of saying yes to everything and hoping.
Currently Taking new clients.
Tell me what's costing you the most right now and I'll tell you whether I can help. If I can't, I'll usually know who can.