Run a stack audit before you refactor anything

Most refactor decisions are made on intuition. The system “feels slow.” The team is “drowning in tickets.” The infra “needs to be modernised.” Engineering leadership writes a multi-quarter refactor plan, gets approval, and starts shipping. Six months in, half the team realises the wrong thing was being refactored, and the actual bottleneck is somewhere the plan didn’t touch.

The cure is a stack audit. Two to four weeks of focused diagnostic work, producing a written brief that tells you what is actually broken, what is fine, and what the right intervention is. The audit costs less than 5% of the refactor it prevents — or scopes correctly.

What an audit covers

A stack audit isn’t a code review. It’s a diagnostic across six dimensions:

1. Architecture. What is the actual topology? Where are the boundaries? Where do they leak? Which decisions made sense three years ago but don’t now?
2. Cost. What does each component cost — infra, licences, ongoing maintenance, opportunity cost of engineering time? Where is the bill compounding?
3. Performance. Where is the system actually slow? Measured, not felt. P50, P95, P99 latencies under realistic load. The bottleneck is rarely where the team thinks it is.
4. Reliability. Incident history. Mean time to recovery. Patterns in postmortems. Single points of failure.
5. Velocity. How long does a representative change take to ship? Where does it stall — review, test, deploy, post-deploy validation? PR cycle time is a leading indicator.
6. Talent fit. Does the current team have the skills to operate the current system? More importantly, does it have the skills to operate the proposed refactor? Refactors that require skills the team doesn’t have are the most expensive.

A 2–4 week audit produces a 15–40 page written brief touching all six dimensions, with a short executive summary up front and a prioritised intervention list at the end.

What the audit changes

In our experience across ~25 audit engagements, the audit shifts the refactor decision in roughly this distribution:

• 20% — confirms the original refactor plan, sometimes with scope adjustments. Team proceeds with high confidence.
• 40% — refactor scope is significantly reduced. The actual bottleneck is smaller and more localised than the original plan.
• 25% — refactor is replaced with a non-refactor intervention. Could be a cost-only fix (replace one expensive SaaS), an operational fix (better on-call rotation), or a process fix (PR review SLA).
• 15% — refactor is escalated. The original plan undersized the problem; the brief recommends a larger investment, often phased.

In all four buckets, the audit pays for itself in averted misallocation. The 40%-reduced bucket saves the most absolute capital; the 15%-escalated bucket saves the most strategic risk.

What the audit doesn’t do

It doesn’t make the decision for you. The brief is a written assessment with prioritised recommendations and explicit risks. The decision to act on it stays with engineering leadership and the CFO. Some companies act on the brief immediately; others sit on it for a quarter while organisational alignment catches up.

It also doesn’t generate the refactor work. A separate Build or Upstream engagement does that. The audit is deliberately a small, vendor-neutral artefact — you should be able to take the brief to a different vendor for execution if that produces a better quote.

When to audit

Three signals that an audit is timely:

1. A multi-quarter refactor is being scoped. Always audit before committing.
2. The infra bill is rising faster than usage. Either misallocation or runaway tooling. The audit identifies which.
3. Engineering velocity has slowed and the team can’t articulate why. Felt-but-not-measured slowdowns are usually multiple small drags. The audit measures.

When not to audit: small, well-scoped problems where the diagnostic cost exceeds the intervention cost. If the problem is “we need to replace one library across 40 files,” just do it.

What you get from us

Our Strategy engagements are 2–4 week fixed-price audits, scoped against the surface area of the system. Deliverable is a written brief, a 60-minute walkthrough with the engineering and finance leadership, and a 30-day follow-up call to validate that the recommendations are landing in execution.

The brief is yours. We don’t tie it to a follow-on engagement. If you want us to execute the recommended work, we’ll quote a separate fixed-price Build or Upstream engagement. If you want to take the brief to a different vendor, we’ll wish you well.

Read more: /strategy/ · /method/ · /about/