The usage figures were unambiguous. Fewer than one user in nine thousand had touched the feature in the preceding year, and the code that supported it accounted for a disproportionate share of the team's maintenance burden. The decision to remove it was therefore straightforward, and was taken in the ordinary way: a deprecation notice, a six-month window, an announcement in the release notes that nobody read. The removal shipped in March. What followed was instructive. Support volume rose by a factor of forty within a week, and the complaints came overwhelmingly from a category of user the metrics had not been designed to see. The feature was used rarely by almost everybody and constantly by a very small number of people for whom it was load-bearing. Averaged across the base, it looked dead. Disaggregated, it was the single most important thing the product did for perhaps three hundred users, several of whom were institutions. This is a well-documented failure mode and the team knew about it in the abstract. Knowing about it in the abstract turned out to provide almost no protection, because the metric that would have revealed the pattern was not one anybody had thought to construct. They had measured how many users touched the feature. What mattered was how many users would be unable to continue without it, and that is a different question with a different answer. The engineer who led the removal wrote an internal note afterwards that circulated more widely than intended. Her argument was not that the decision had been wrong on the evidence available, but that the evidence available had a shape, and the shape was determined by what was cheap to count. Frequency is cheap. Dependence is expensive, because establishing it requires asking rather than logging. She was explicit about the limits of the lesson. It does not follow that nothing should ever be removed; a product that cannot delete anything eventually collapses under its own history. Nor does it follow that a loud minority should always prevail. The three hundred users were, by any commercial reckoning, not worth the maintenance cost. What follows is only that the team had believed it was making a decision about an unused feature, and was in fact making a decision about a small number of dependent users, and had no idea it was doing so until after the fact. The feature was restored in April, in reduced form, with a note in the documentation describing it as unsupported. It has not been touched since. The maintenance burden it was removed to avoid is still being paid, now with the additional overhead of a second code path and a support policy nobody can quite articulate. Nobody on the team regards this as a good outcome. Nobody has proposed removing it again.