Selected work

The problem,and what changed.

Every project is written the same way: what was wrong, what we did, the number that moved, and what we'd change. Including the bits that went badly. A list of only wins is an ad, not a portfolio.

40+Products delivered since 2019
11Systems we run in production today
7Countries clients operate from
68%Of work comes from repeat clients

Note for review: the five studies below show the format. Swap in real client descriptions and numbers before this goes live.

Logistics platformNetherlands14 weeksPod of four

A nightly process that had grown from twenty minutes to over four hours

9 minRuntime, down from 4h 12m
0Overruns into business hours since
14Weeks end to end

The problem

An overnight reconciliation job had crept from twenty minutes to over four hours and regularly ran into the working day, delaying every downstream report. Nobody remaining on the team had written it, and the two engineers who understood it had left eighteen months earlier.

What we did

Profiled before changing anything. Two queries accounted for most of the runtime, so those were rewritten first and the remainder moved to incremental processing. We then added a regression test that fails the build if the job ever exceeds fifteen minutes. The problem was slow creep, so the fix had to include a tripwire.

The constraint

No downtime window was available, and there was no staging environment holding production-scale data. Building one became the first milestone rather than an assumption, which is where the schedule initially slipped.

What we would do differently

We lost three weeks building a staging environment because we assumed one existed. That question now belongs in the first call, not the first sprint.

Insurance groupUnited Kingdom20 weeksFixed scope

Forty years of policy documents that nobody could search

84%Accuracy on the approved question set
11 minMedian time saved per case
100%Processing inside client infrastructure

The problem

Underwriters spent hours locating precedent across four decades of scanned policy documents. Terminology had changed three times, optical character recognition on the older material was poor, and the existing search returned everything or nothing.

What we did

Wrote the evaluation set first: three hundred real questions with answers approved by senior underwriters, before any retrieval code existed. Every later change was measured against it. Ordinary keyword search turned out to answer four queries in ten perfectly well, so we kept it and routed only the rest to a model.

The constraint

No document could leave the client's own cloud tenancy, which ruled out several obvious approaches and shaped the architecture from day one rather than being retrofitted at the security review.

What we would do differently

We under-scoped document cleanup by about three weeks. On any archive older than fifteen years, that work now gets budgeted explicitly instead of being treated as preparation.

Health technologyUnited StatesOngoingTwo embedded engineers

Taking over a codebase after every original author had left

5 daysTo a written assessment, fixed fee
61%Test coverage on core paths, from 3%
2 wksTo the first safe production deploy

The problem

Following an acquisition, the entire engineering team departed within four months. The product worked and had paying customers, but nobody could change it safely, and releases had quietly stopped altogether.

What we did

A five-day written assessment at a fixed fee before quoting anything: what existed, what was dangerous, what it would cost to make safe. Then characterisation tests around the modules that changed most often, a deployment pipeline you could trust, and a written map of the system.

The constraint

Active customers throughout, and clinical data with regulatory obligations. A rewrite was never on the table, and we did not recommend one.

What we would do differently

Nothing structural. Assessment-before-quote became mandatory on all takeover work because of this one. It has since talked two prospective clients out of hiring us, correctly.

B2B SaaSGermany9 weeksTwo engineers

When the analytics and the database disagreed by nine hundred customers

<1%Variance, analytics against database
18 moOf reporting restated and documented
1Number of signup figures, now

The problem

Marketing reported 3,100 signups for the quarter. The production database held 2,240. Both numbers were being presented to the board, by different people, in the same meeting, and nobody could explain the gap.

What we did

Rebuilt tracking around server-side product events rather than client-side page views, then reconciled every historical discrepancy so the board could see which prior quarters had been wrong and by how much. The method was documented alongside the restated figures.

The constraint

Eighteen months of published reporting could not simply be discarded. It had to be restated openly, which is a harder conversation than starting fresh but the only defensible one.

What we would do differently

The finance director should have been in the first workshop. We treated it as an engineering problem for two weeks before recognising it was a reporting-governance problem with an engineering component.

Industrial manufacturerUnited Arab Emirates16 weeksFixed scope

A CRM that had drifted so far from reality the team kept a spreadsheet

-41%Custom objects after cleanup
2Internal administrators trained
0Historical dashboards lost

The problem

Eight years of accumulated Salesforce customisation, three departed administrators, and a sales process that had moved on without anyone updating the system. The team had quietly reverted to a shared spreadsheet, which meant the CRM's reports were describing a process nobody followed.

What we did

Shadowed the sales team for a week before touching the org, then mapped what they actually did. Removed considerably more than we added, integrated the result with the customer portal we had built the previous year, and trained two internal administrators with written documentation.

The constraint

No reporting continuity could be lost. Every historical dashboard had to survive the migration intact, which constrained how aggressively we could restructure the data model.

What we would do differently

Shadow the team before the mapping workshop, not after. What managers described and what the spreadsheet showed differed in three material ways, and we found that out a fortnight later than we should have.

Where we work

Sectors we've
done enough work in.

We are not specialists in any one industry. There are domains where we have made enough mistakes to be useful early, rather than after three months of catching up.

Logistics & supply chainReconciliation, tracking, integration-heavy systems
Insurance & financial servicesDocument-heavy workflows, regulated data
Health technologyClinical data, audit trails, regulated deployment
B2B SaaSMulti-tenant products, analytics, growth instrumentation
Industrial & manufacturingIoT telemetry, enterprise platforms, portals
MarketplacesSearch, matching, payments integration

On confidentiality

Why some clients
aren't named.

Some engagements sit under agreements that don't allow us to name the client.

Where we can't name a client, we still say the sector, region, stage, engagement shape and duration, and we publish the numbers. Specific and anonymous is more useful than named and vague.

If you want to speak to a client directly, we will arrange it. Several have agreed to take reference calls, including one where the engagement ended early. Better you hear that from them.

Want the long version of any of these?

We'll walk you through the decisions, including the ones that turned out wrong. Half an hour, free, and usually more useful than a pitch.