The Library · Perspective
Cost reduction that survives contact
Most software cost programmes move cost rather than remove it. A note on which reductions hold, and which reappear two quarters later under another name.
Software budgets are under real pressure, and the pressure has produced a familiar set of moves. Some of them remove cost. Most of them relocate it, and the relocation is invisible for long enough that the programme is judged a success before the bill arrives.
The distinction that matters
A cost is removed when the work stops being necessary. A cost is moved when the work is still necessary and is being done somewhere the budget cannot see it — by a different team, by the customer, or by the same team later at a higher rate.
Almost every disappointing efficiency programme is a moved cost that was accounted for as a removed one.
Reductions that tend to hold
Deleting features nobody uses. The only reliably permanent saving in software. It reduces surface area, test burden, support load, and cognitive cost simultaneously, and none of it comes back. It is also the hardest to get approved, because someone advocated for each of those features.
Reducing the number of systems that do the same job. Consolidation is genuinely hard and genuinely permanent. The saving is not the licence fee; it is the integrations, the reconciliations, and the arguments about which number is correct.
Shortening the feedback loop. Anything that makes a defect cheaper to find lowers cost permanently, because the cost of a defect scales with how late it is caught. This is the least fashionable item on the list and usually the highest return.
Raising the cost of adding, not the cost of maintaining. Teams under budget pressure tend to squeeze maintenance, which is the one thing that compounds. Putting friction on the front door works better than starving the back.
One basin drains and its neighbour fills by the same amount. Only the small trail leaving the frame at the top right was actually removed; everything else was relocated.
Reductions that tend to reappear
Cutting QA. The work does not stop; it is transferred to customers, who report defects at a far higher unit cost, and to engineers, who now context-switch to fix them. This is the single most reliable way to convert a visible cost into a larger invisible one.
Cutting documentation. The cost reappears as onboarding time and as the same question being answered repeatedly by whoever knows.
Offshoring without changing the interface. Moving the same undefined work to a cheaper team lowers the rate and raises the number of hours, frequently past parity. Where it works, it works because the work was specified properly as part of the move — and the specification, not the rate, was the saving.
Replacing specialists with generalists plus tooling. Effective for well-bounded work with a clear correctness standard. Expensive where the specialist's value was knowing which of several plausible answers was right.
Where AI genuinely changes the arithmetic
It changes the cost of producing a first draft of almost anything: code, tests, documentation, migration scripts, boilerplate. That is a real and large reduction, and firms that are not taking it are leaving money on the table.
It does not change the cost of deciding whether the draft is correct. That cost is now a larger proportion of the total than it used to be, which means the constraint has moved rather than disappeared.
The firms getting the durable saving are treating generation as a way to spend less time on the parts that were never the bottleneck, and reinvesting some of it in the part that now is.