I am the engineer CTOs call when the problem is genuinely hard.

Not a fractional CTO. A fractional IC, at staff and principal level, brought in when an internal team has hit a wall and needs someone who has solved that class of problem before. My clients are CTOs, VPs of Engineering, and technical founders. The arrangement is simple: they have a problem their team cannot get past, and I come in and solve it.

I work in two areas where that wall comes up most often: entity resolution at scale, and the discipline of making AI-generated code safe, fast, and correct. Both come from close to twenty years of building serious software in fast-growing companies, the majority of it in domains where getting it wrong was expensive and the feedback was unforgiving.

Entity Resolution

Entity resolution, deciding when two records refer to the same person or company, is one of the hardest problems in data-intensive systems. At scale, with incomplete and inconsistent data, it is technically demanding, operationally unforgiving, and badly served by the assumption that the right tool will solve it. Most teams that get it wrong do so at the start, when they mistake it for a simpler problem than it is.

I am one of a very small number of independent practitioners with deep, hands-on entity resolution experience at scale, built over eleven years in financial crime compliance. I was a founding engineer at ComplyAdvantage and latterly the Staff Engineer responsible for the technical direction of its entity resolution. 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 alongside data scientists, in a domain that does not forgive bad matches in either direction.

The problem is domain-portable. It appears in healthcare, logistics, insurance, public sector data, and anywhere an organisation needs a reliable view of its customers or counterparties. The work I am brought in for:

Build vs buy. Most teams underestimate what building takes and over-trust what vendors claim. I give an honest assessment of what a vendor actually delivers, what you would need to build yourself, and where the real costs and risks sit.

Vendor and infrastructure selection. Which questions to ask, which claims to stress-test, and what the contract should protect you against.

Architecture review. Is your ER system built 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. What "good enough" matching means for your use case, where precision and recall trade off in practice, and where the real risks accumulate.

AI-Empowered Development

This is not AI strategy. It is the specific engineering discipline of making AI generation safe, fast, and correct: model-first thinking, harness engineering, contract tests that keep the fast path honest. The work that decides whether a team's AI output compounds or piles up as wrong-direction code.

Most teams adopting AI are either generating code faster in the wrong direction, or bolting AI onto their workflow with no change to how they think about design, modelling, or verification. Neither produces the returns AI actually makes available.

I install the discipline alongside a team, not as a workshop: harness engineering, model-first design, the test architecture and feedback loop that make iteration trustworthy. For technical leaders, I also advise on how to lead an AI-empowered engineering organisation: what to measure, what to protect, where the risks compound, and how to avoid reaching for process when the real problem is direction.

How I Work

I work on a project-bounded basis, not an open-ended retainer. I am brought in for a specific hard problem, with a clear scope and a clean exit. Typically two to three days a week, and no more: enough to make real progress embedded with your team, structured so the work stays focused and the engagement ends when the problem is solved.

I work with your engineering leadership, not in place of it. Your team owns the system. I bring the experience they are missing on the problem in front of them, and I leave them better equipped to handle the next one.

Background

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

I joined ComplyAdvantage in 2014 as one of its first five employees and built the foundational data pipeline that powered its products from the start. Over eleven years, through rapid growth and significant scale, I worked across transaction monitoring and entity resolution: sanctions screening, AML data processing, and financial crime detection. 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 Staff Engineer responsible for the technical direction of entity resolution.

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 a team produces 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, and the blast radius of a bad decision grows before anyone notices.

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

Engage

I work remotely, with some availability in London. Rate: £1,000–£1,500 per day depending on engagement. I am available from August 2026. If your team has hit a wall on a hard problem in a technically complex domain, get in touch.