The Cost of Keeping What You Should Remove

Every product I have worked on has features that cost more to keep than they are worth. Not broken features. Not controversial ones. Features that work fine, get used by almost nobody, and sit there quietly taking up space.

I have kept features like that alive for years. Not because they added value, but because removing them felt like more work than leaving them in place. They worked. They were not hurting anyone. Why bother?

That reasoning felt pragmatic at the time. I have since learned it is the most expensive form of laziness in software.

The lie we tell ourselves

"It works, so it is free to keep."

This is what we say when we do not want to think about it. And for a while, it's true. The features sit there, untouched, collecting dust. Nobody complains. Nobody celebrates. They just exist.

But software does not work like this. Dependencies shift. Frameworks update. Security patches ripple through layers you forgot were connected. Those quiet features are not free. They are accumulating debt.

I learned this the hard way many times. A release went out, and three weeks later a bug report came in from a single user clicking a button I had forgotten existed. Someone had to context-switch, investigate, trace the regression, fix it, and report back. Half a day of engineering time for a feature that served one person who probably would not have noticed if the button had simply disappeared.

That was one feature, one bug report. Now multiply it across every neglected corner of a product.

The weight you stop noticing

One unused feature is manageable. You barely think about it. But products do not collect one. They collect dozens, quietly, over years. A toggle nobody clicks. A report nobody reads. An export format nobody requests. Each one seemed harmless when it shipped. Each one still seems harmless on its own.

But collectively, they change the shape of every conversation. A design review takes longer because the interface has no space left. A dependency upgrade touches code paths nobody remembers writing. A new engineer spends their first week building a mental model of a system where a third of it serves no one.

In some occasions, removing unused features is not even on the table. Not because anyone defends them, but because nobody can confidently say which ones are unused. The tracking might not be there. Or maybe the institutional knowledge had left with the people who built them.

That is how it compounds. Not through any single decision, but through the absence of decisions. The features you never question become the ones that define your constraints.

Why we still keep them

I think the real reason we keep unused features is not pragmatism. It is discomfort.

Removing a feature feels like admitting failure. Someone built it. Someone approved it. Maybe it was your idea. Deleting it means acknowledging that the effort was, in some sense, wasted.

I have felt that discomfort. I have argued to keep things I built, not because they mattered to users, but because they mattered to me. That is not product thinking. That is ego dressed up as engineering judgment.

There is also the fear of the edge case you cannot see. What if that one user depends on it? What if removing it breaks something downstream? These fears are real, but they are also answerable. Usage data exists. Conversations can be had.

The fear of finding out is not a reason to avoid looking. And certainly not, when you can just bring the feature back if complaints come in.

When keeping is the right call

I do not think the answer is to remove everything with low usage. Some features serve a small audience that depends on them deeply. Some could exist because of contractual obligations or regulatory requirements. Some are niche but genuinely valuable for power users.

There is a difference between keeping a feature because you evaluated it and decided it still earns its place, and keeping it because nobody bothered to ask the question.

The discipline of subtraction

Every feature has a rent. Some pay for themselves through usage, through value, through the problems they solve. Others just accumulate cost quietly, making everything around them a little harder, a little slower, a little more constrained.

Adding features is easy to celebrate. Shipping feels good. But the products I admire most are not the ones with the most features. They are the ones where every feature earns its place. Where someone had the discipline to ask: does this still serve the people using this product?

The discipline is not in building more. It is in being honest about what deserves to stay.