Selected work

A system,
carried through change.

One engagement, in detail. Other problem spaces are listed at the end of the page.

The clearest illustration of how we work is an engagement that lasted several years on a single customer-facing CRM. The system was already in production when we joined it. Over time it absorbed external integrations, a document workflow, a billing layer, scheduled jobs, and a transactional email pipeline. None of those pieces had been planned together. Each had been added at the moment it was needed.

The day-to-day work was a mix of corrected defects, new behaviour asked for by the business, and a steady, deliberate effort to keep continuous deployment honest as the surface area grew. Underneath that, a slower piece of work ran the whole time: locating the implicit boundaries the system had grown around and making them explicit.

What the system was doing to itself

Complexity had compounded in the usual ways. Two modules read the same record with subtly different expectations. A queue consumer assumed an invariant the producer had stopped guaranteeing. A field on a form had three meanings depending on which path created it. Individually small. Together, the source of most of the noise.

Where the work went

  • Restating boundaries between modules so each owned a single concern.
  • Stabilising behaviour at the seams, not by patching every caller.
  • Removing components that no longer paid for the maintenance they cost.
  • Surfacing constraints that had been carried implicitly for years.

The tradeoff in writing

Speed, stability, and flexibility were named openly as the three axes in tension, and each major decision picked which two it would favour. The result was a system that became more predictable to operate and easier to extend, in exchange for periods where new feature work slowed deliberately while a structural change was finished.

Other problem spaces

The shape varies. The discipline does not.

Deployment pipelines

Inconsistent artefacts traced back to implicit ordering between build and release.

Data drift

Datasets that had quietly diverged from the schemas describing them, recovered without downtime.

Real-time instability

Timing assumptions that held in test broken under realistic load, then corrected at the protocol layer.

AI product foundations

A retrieval and evaluation pipeline replacing a brittle prompt-only prototype.