The previous piece was about code nobody can prove is unused. This one is about the harder case: the feature that demonstrably is used, by two customers, once a month. There’s no ambiguity to resolve — the usage data exists and says someone depends on it. And that’s exactly what makes it stick, because “two customers would be affected” ends the conversation before anyone weighs it against what the feature costs everyone else.

The cost is real and mostly invisible. It’s a section of the interface that every new user has to understand well enough to skip. It’s a code path every refactor has to preserve, a set of behaviors every migration has to carry forward, a corner of the product that documentation, support training, and testing all have to cover. None of that shows up as a line item; it shows up as everything being slightly slower and slightly more complicated than it needs to be. Meanwhile the benefit — two customers, once a month — is easy to name precisely, which makes the comparison feel lopsided in the wrong direction.

What makes the decision tractable is turning “someone uses it” into a comparison. How much revenue is attached to those users, and is it attached to this feature or just to them? What does the feature cost per year in maintenance, support, and drag on unrelated work? Is there another way to serve the same need — an export, a manual process, a workaround support can run — that costs a fraction as much? These questions have approximate answers, and approximate answers are enough. The failure mode isn’t choosing wrong, it’s never asking, and defaulting to permanence because removal requires a conversation and keeping doesn’t.

When the decision is to remove, the humane version isn’t complicated: tell the affected users directly rather than in a changelog nobody reads, give a real timeline, and say what to do instead. Most people are far more reasonable about a feature going away with notice and a path forward than they are about discovering its absence during their workflow. What generates lasting damage is the silent removal, the surprise, the sense that the product changed underneath them — not the removal itself.

And it’s worth being honest that sometimes the answer is to keep it. A feature two customers use might be exactly the feature those customers renew for, or the thing that makes the product credible in a segment you care about. The point of the exercise isn’t to reach a predetermined conclusion; it’s that “someone uses it” should be the start of the analysis rather than the end. Products don’t get bloated because anyone decided to add weight — they get bloated because nothing ever gets weighed.