I work with engineering teams, technical leaders, and companies facing two of the harder problems in software: building a development discipline that makes AI generation safe and fast, and getting entity resolution right at the scale and complexity where most approaches break down.

Both offers come from the same place: close to twenty years of building serious software in successful, fast-growing companies, the majority of it in domains where the cost of getting it wrong is high and the feedback is unforgiving.

AI-Empowered Development

Most teams adopting AI are either generating code faster in the wrong direction, or treating AI as a productivity bolt-on with no change to how they think about design, modelling, or the discipline that makes generation trustworthy. Neither produces the compounding returns that AI actually makes available.

The offer here is specific. Not AI strategy in the abstract. The discipline of using AI well: model-first thinking, harness engineering, the feedback loop that makes generation safe and fast. Installed alongside a team, not delivered as a workshop.

For engineering teams: embedded or advisory engagements to establish the development discipline. Harness engineering, model-first design, test architecture, the agentic flywheel that makes iteration trustworthy. A working practice, not a one-off training.

For technical leaders: coaching on how to lead an AI-empowered engineering organisation. What to measure, what to protect, where the risks compound, how to avoid the trap of reaching for process when the problem is actually direction.

For companies: architecture review with an AI-readiness lens. Is the codebase a good place for AI to work? Where is the direction risk? What would need to change?

Entity Resolution

Entity resolution, the problem of deciding when two records refer to the same person or company, appears in financial crime compliance, healthcare, insurance, logistics, public sector data, and anywhere organisations need a reliable view of their customers or counterparties. At scale, with incomplete and inconsistent data, it is one of the hardest problems in data-intensive systems: technically demanding, operationally unforgiving, and poorly served by the assumption that it can be solved by simply buying the right tool.

I spent years working on entity resolution at depth, including as Staff Engineer responsible for its technical direction at ComplyAdvantage, one of the leading names in financial crime compliance. I have designed and built ER systems in batch and streaming contexts, worked with graph databases at scale, and developed and evaluated ML-based matching algorithms alongside data scientists. The domain where I earned that experience is high-stakes, regulated, and unforgiving of bad matches in either direction.

The vendor landscape for ER is opaque. The build-vs-buy decision is poorly understood. Most teams that get it wrong do so at the beginning, when they mistake the question for a simpler one than it is.

Build vs buy advisory. Most teams underestimate the complexity of building and over-trust vendor claims about buying. I can give an honest assessment of what you are actually getting from a vendor, what you would need to build yourself, and where the real costs and risks sit.

Vendor selection. Evaluating ER vendors, data providers, and underlying infrastructure. Knowing which questions to ask, which claims to stress-test, and what the contract should protect you against.

Architecture review. Is your ER system designed for your scale and operational requirements? Batch, streaming, or both? Where are the matching decisions made, and are they auditable? What are the feedback loops?

Domain advisory. The context that technical teams often lack: what "good enough" matching means for your use case, where precision and recall trade off in practice, and where the real risks accumulate.

Background

Close to twenty years of software engineering, the majority of it in financial crime and regulated data systems, and almost all of it in companies that were building something real under genuine pressure.

I was a founding member of the technical team at ComplyAdvantage, joining in 2014 when the company was just beginning to establish itself as a serious player in financial crime compliance. Over eleven years, through rapid growth and significant scale, I worked across the data pipeline, transaction monitoring, and entity resolution: building systems for sanctions screening, AML data processing, and financial crime detection at scale. I managed teams, drove architecture across multiple domains, and watched a transaction monitoring product go from prototype to $7m ARR. My most recent role there was as Staff Engineer responsible for the technical direction of entity resolution, one of the harder problems in the FRAML space.

I am currently Founding Engineer at Diligent, an early-stage company building a KYB/KYC platform that combines domain expertise, LLMs, and modern infrastructure to fight financial crime.

My background is in mathematics: undergraduate and MMath from Cambridge. The habit it instilled is the one I reach for most often: demand that the model be correct before you proceed.

The Point of View

AI raises the speed at which teams produce output. It does not change what makes that output correct. A team without a clear model, clean interfaces, and honest verification will produce wrong-direction code faster than it ever could before. The blast radius of a bad decision grows before anyone notices.

The discipline I write about and consult on is the discipline I have applied throughout a career in systems where getting it wrong was not an option. The blog is the working record of that position.

Engage

I work remotely, with some availability in London. Rate: £1,000–£1,500 per day depending on engagement type. I am available for engagements from August 2026. If you are building something serious in a technically complex domain and want to talk, get in touch.