I lead engineering and product for systems that have to hold up in the real world.

Twenty years across healthcare, financial services, and ventures of my own. The work sits where applied AI, enterprise architecture, and business development meet — and where none of those three is useful without the other two.

I have shipped CRM platforms, compliance-heavy workflow engines, data systems that auditors can actually trust, and applied AI that runs in the cloud and on the edge. The pattern is consistent: understand the commercial problem, design the system that runs it, and stay close enough to build it.

Most of my career has been inside large enterprises. I have also started businesses, designed brands, and operated products end to end. That mix is not a side interest. It is how I keep product judgment honest.

Where I spend my attention

AI and machine learning. Intelligent workflows, applied integration, data engineering, and inference that holds up outside a demo. I care about the design patterns that make a model useful in a production system — including local LLM inference and edge execution when latency, cost, or privacy make the cloud the wrong default.

Enterprise product design. Complex platforms, multi-tenant workflows, and software that maps to how an organisation actually operates. I have led architecture and delivery for systems used by health plans, asset managers, and internal teams who do not have time for a product that almost works.

Business development as an engineering problem. Lead lifecycles, partner onboarding, speaker and pipeline operations, revenue workflows. Product vision only matters if engineering is pointed at the commercial motion.

What I believe about this work

A new source should be a configuration entry, not a new codebase. If onboarding your sixth partner costs what the first one did, the problem is architectural. Parameterise the ingestion, build reconciliation into every load, and the cost curve flattens.

Choose the design whose failures you can survive. When two approaches are close on merit, the tiebreaker is what happens when you get it wrong. A missed row-level policy denies access. A missed application check leaks data. That asymmetry should decide the architecture, not developer convenience.

Software nobody trusts is worse than no software. Reconciliation, lineage, and a dictionary somebody actually reads are not overhead on the real work. They are what makes the real work usable.

Stay close enough to build. I lead, review, and set standards. I also still write the code, tune the jobs, and get paged. The day I cannot do that is the day my architecture calls stop being credible.

Outside the day job

I build and operate ventures. The Enterprise & Ventures page covers a hospitality concept I designed from brand through supply chain, plus the SaaS tooling and AI experiments I run myself.

I play chess at a level that keeps me honest, and I have never met a puzzle I could leave alone. Both are the same instinct as the day job: look at a position, work out what is actually true, and commit.

Get in touch

I am open to conversations about engineering and product leadership, enterprise platforms, and applied AI. The fastest way to reach me is email.