Three cases, set out in full: the situation, the difficulty, the work and the outcome.

Situation

An expert network holding years of recorded interviews. Each recording had been paid for once, delivered to one client, and then sat in storage. The commercial question was whether that corpus could become a data service that sells repeatedly, at a margin, without creating a compliance incident on the way.

The hard part

The recordings are not clean. Calls arrive over conference bridges, VOIP and mobile handsets, and the word error rate does not spread itself evenly across a transcript. It concentrates on exactly the tokens carrying the value: the ticker, the compound, the drug name, the number. A transcript that is accurate everywhere except the words a client is paying for is worth nothing.

Interviews are multilingual, and speakers switch language inside a sentence, so language has to be identified per segment rather than per file. Speakers overlap. Attribution is not a nicety: recording a client’s question as an expert’s assertion turns a transcription error into a compliance event.

Then there is everything the model never touches. MNPI has to be screened before content moves anywhere downstream. Consent scope and reuse rights vary by contract and by jurisdiction, so two identical recordings can carry different permissions. A GDPR erasure request has to propagate past the source record into embeddings, indexes and every derived artefact built from it.

Evaluation was its own problem. Deciding whether a summary of a specialist conversation is correct needs domain expertise, at a volume nobody can read. And all of it had to hold its unit economics at corpus scale, where a per-file cost that looks trivial in a pilot is fatal across millions.

What was built

An AI based data service on an event-driven Temporal architecture, so that long-running work with partial failures could be retried, versioned and audited at the segment level. Per-segment language identification, diarisation with speaker attribution, and domain vocabulary biasing for tickers, compounds and drug names.

Compliance was built outside the model rather than prompted into it. Consent and reuse rights travel with the asset, MNPI screening gates the pipeline, and erasure propagates through the derived indexes. Evaluation was built as sampling against expert-labelled sets with drift monitoring, rather than as review by eye.

Outcome

An AI based data service, turning a corpus that had been paid for once into a line that sells repeatedly.

Every competitor had the same recordings, the same models and the same price list. The difference was in the parts that are not the model.

Situation

An engineering organisation asked to adopt AI tooling, and a board asking what the spend had bought. The available answers were vendor benchmarks and developer sentiment, neither of which survives contact with an audit committee.

The hard part

Measuring the result rather than estimating it.

Productivity claims in this area are usually built from self-reported time savings, or from counting the code an assistant produced, which measures typing rather than delivery. Neither tells a board whether anything reached a customer sooner. The measurement had to run on data the organisation already generated in the course of doing the work, so that the number could not be shaped by the people being measured.

The second difficulty was that adoption is an organisational change, not a licence purchase. Tooling put in front of an engineer who has no time allocated to learn it, no change in review practice, and no target attached, produces a pilot that quietly stops. The programme had to move working practice and measurement at the same time.

The third was attribution. An engineering organisation is never doing only one thing at once. A productivity figure has to be defensible against the obvious challenge that something else caused it.

What was built

DORA metrics instrumented in LinearB and integrated with Jira, giving deployment frequency, lead time for change, change failure rate and time to restore on live data rather than on a survey. A baseline was established before rollout.

An adoption plan by team, with the tooling, the practice change and the target moving together. The outcomes were carried in OKRs cascaded to every head of function, with quarterly roll-up to the board, so the programme was owned across the organisation rather than by an engineering initiative.

Outcome

A 73% productivity increase and a 35% cost reduction, measured against the instrumented baseline.

This was an organisational result rather than a model result. The tooling was available to everyone in the market at the same price. What made the difference was the measurement apparatus, the practice change alongside it, and the accountability sitting with the heads of function rather than with a pilot team.

Situation

A community platform growing faster than the architecture underneath it. Traffic was arriving on a schedule nobody controlled: a broadcast mention, a news cycle, a thread that found a wider audience than the site was built to serve.

The hard part

Community traffic is spiky in a way that commerce traffic is not. Load does not build through a funnel that can be forecast from the top. It arrives in minutes, concentrates on a small number of very active discussions, and is dominated by reads of content being written at the same moment, which is the least cacheable state a page can be in.

The platform also could not be taken down to be improved. A community site is used continuously, and the tolerance for a maintenance window on a discussion people are in the middle of is close to zero. Every change had to be made underneath live traffic.

Resilience at this level is mostly a design question rather than an infrastructure purchase. Five-nines uptime means the failure of any single component cannot be visible to a reader, which puts the work into how state is held, what is cached and for how long, and how the system behaves when a dependency is slow rather than when it is absent.

There is a cost dimension underneath all of it. Provisioning permanently for the largest spike is straightforward and unaffordable. Capacity has to track demand closely enough that the platform is not paying year-round for a peak it sees a handful of times, while still absorbing that peak on the day it arrives with no notice.

What was built

Platform architecture on AWS, designed for elastic capacity against unforecastable peaks, with caching and failure isolation such that component failures degrade quietly rather than visibly.

Outcome

The platform scaled from a small community to over 10 million unique monthly visitors, held at five-nines uptime.