Anatomy of a tiger team: 140k lines of dead code and $2M saved

The client was a consumer lending group whose loan origination platform had been in production for twelve years and had consumed roughly three quarters of their engineering budget for the last four. Two vendors had already attempted a stabilisation. Both had started by proposing a rewrite.

We proposed three weeks of doing nothing but measuring. That is not what a room full of executives who have just spent eighteen months on failed remediation wants to hear, which is why the first part of this story is about politics.

Weeks 1–3: instrument, do not touch

We added distributed tracing, turned on query logging with sampling, and — the highest-value thing we did all quarter — deployed a code-coverage agent against production traffic rather than the test suite. The question was not "what is covered by tests" but "what actually executes when real customers use this."

The answer was that 140,000 lines of the codebase had not executed once in thirty days. Entire modules for products the business had discontinued in 2019 were still being compiled, deployed, security-scanned, and — critically — still being reasoned about by every engineer who touched adjacent code.

Weeks 4–7: delete, then optimise

Deletion is the cheapest performance optimisation in existence and the hardest to get approved. We staged it: feature-flag the module off, watch for thirty days of production traffic, then remove. Build times fell 41%. The security scan queue, which had been the single largest source of release delay, dropped from four hours to under one.

Only then did we look at the settlement batch — the job that ran nightly on a permanently provisioned cluster sized for a peak it hit twice a year. Moving it to an event-driven serverless pipeline took four weeks and removed the largest single line on the infrastructure bill.

• 140k lines removed across nine dormant modules
• Build time: 22 minutes → 13 minutes
• Nightly settlement: fixed cluster → serverless, scaled per volume
• Cloud run-rate: down 63%
• Total annualised saving: approximately $2M

Weeks 8–11: hand it back

A tiger team that becomes permanent has failed. The last four weeks were pairing, documentation and building the dashboards the client's own team would use to catch the next regression. We wrote the runbooks with their on-call engineers rather than for them, which took longer and meant they were actually used.

What we would do differently

We under-communicated in weeks one to three. Measuring looks like inactivity from the outside, and we let a fortnight pass without showing anything to the steering group. On subsequent engagements we now publish a weekly finding — even a small one — from day three. The instrumentation phase does not get shorter, but the anxiety around it does.