Teams plan what to build every quarter and almost never plan what to remove. The result is a product where a quarter of the surface area serves a handful of people and slows down everything else.
What an unused feature costs
It is not the disk space. It is the test suite that has to keep passing, the migration that has to keep working, the permission model that has to keep accounting for it, and the fifteen minutes every engineer spends understanding it before deciding it is irrelevant to their change.
How we find them
- Instrument first. Usage per feature per month, by account, not by page view.
- Ask the support queue. Anything nobody has ever asked about is a candidate.
- Check the data. A table with no writes in six months is a feature nobody uses, whatever the roadmap says.
The removal process
Announce it, make it inert behind a flag for a release, watch for complaints, then delete the code, the tables and the tests in one change. Half-removed features are worse than kept ones because they still have to be reasoned about and no longer work.
A codebase gets faster to work in mainly by getting smaller.
The client conversation
It is easier than people expect. Framed as "this costs you money every sprint and eleven people used it last quarter", most owners agree quickly. Framed as "we would like to delete something you paid for", nobody does.
