Write the business case for replacing a component that works but is expensive to change.
Show the full answer Hide the answer
What is being tested
Whether you can argue technical debt in delivery outcomes, with evidence, options and an honest cost of inaction.
The structure
Problem, in delivery terms.
"The last six changes to the pricing component took an average of 14 days. Comparable changes elsewhere take three. The difference is roughly four weeks of engineering capacity per quarter, and the gap has widened each quarter for the past year."
Evidence, and a trend. Not "the code is messy", which is true, unfalsifiable from the funder's position, and loses to a feature every time.
Consequence, in business terms.
"Three roadmap items this year depend on this component. At current change cost they are estimated at nine weeks; with the work done first, four. We have also deferred two pricing experiments because the change cost exceeded the expected value of the test."
The deferred work is the strongest argument available: it is opportunity cost the business can feel.
Options, with costs and benefits.
| Option | Cost | Benefit | Risk |
|---|---|---|---|
| Do nothing | 4 weeks capacity per quarter, rising | None | Widening gap; increasing incident exposure |
| Targeted refactor | 3 weeks | Recovers most of the change cost | Low; incremental and reversible |
| Full replacement | 4 months | Clean model, enables X and Y | High; rewrites of this kind frequently fail |
Presenting the full replacement alongside a cheaper option that captures most of the value is what makes the recommendation credible — and it is usually the honest recommendation, because incremental improvement succeeds where rewrites do not.
Recommendation, with a measurable outcome.
"Targeted refactor. Success measure: change lead time in this component under five days within one quarter, measured from existing data. If it is not achieved we will reassess rather than continue."
Stating the failure criterion is what distinguishes a business case from a request.
Cost of inaction, with the trend, because otherwise doing nothing looks free.
The two tactics that often work better than a funded block
Incremental refactoring inside feature work — improve the area you are already touching, absorbed into estimates. Slower, needs no negotiation, avoids the argument entirely.
Tie it to upcoming features — "the next three roadmap items all touch this; doing the refactor first makes them faster in aggregate." This converts a cost into a schedule optimisation.
What a strong answer adds
Where you would refuse to defer regardless: foundations — data models, security boundaries, tenancy, identity — where shortcuts compound; and debt whose interest is paid in incidents rather than in effort, because that cost is unbounded and arrives without warning.