work

I've actually run a business — not just managed someone else's.

Built a delivery team from nothing, owned the wins and the misses, made the calls that keep a small operation running. That's not theory for me.

Built and ran a delivery business

Took a delivery operation from zero to a 30-person team, owned the P&L end to end, and grew client work 4x through direct partnerships. Learned firsthand what actually keeps a small operation running versus what just looks good on paper.

Years inside bigger programs

Spent time inside banking platforms, healthcare systems, and AI rollouts — learning what solid delivery looks like at scale, so I recognize it (and its absence) quickly wherever I see it.

case study

Automating insurance renewals

The problem: Insurance renewals are a slog — an agent reaches out, coordinates with multiple vendors for quotes, negotiates between the customer and the companies, and chases everyone through several rounds before anything gets finalized. Most of it is repeatable, which means most of it is automatable. The client saw that clearly.

Where it stalled: He tried building the automation himself using AI agents. But knowing an AI can do something and knowing how to design it so it actually does the right thing, reliably, are two different skills. He got stuck exactly where most people do: the system needs to know what to do when someone uploads a document, what changes when a new parameter shows up, what happens to something already mid-process when a rule changes. None of that gets taught by "build me an automation." It has to be designed.

What I brought: I've built and run software long enough to know what questions the system needed answered before anyone touched a prompt. So instead of jumping straight to building, we worked through it together — what should trigger automatically, where the process needed a human checkpoint, how it should flex as things change. Once that was settled, the AI tools did what they're good at.

The point: The AI could write the code. It couldn't have designed the system. That's the part that needed someone who's built software before.

case study

Catching AI when it's confidently wrong

I asked an AI assistant to build a project plan from a stack of meeting summaries. The first few action items were sharp and accurate. A few lines down, they got vague, then started repeating — it had quietly stopped reading the source material and started guessing, without saying so. I caught it, sent it back to actually read the emails, and got a corrected plan. The lesson: AI can look right long enough to earn your trust before it's wrong. Someone still needs to know the material well enough to catch that moment. That's the loop I sit in.