14 Apr 2026 · by Rehan Azaz

The cheapest feature is the one you delete

OpinionEngineeringMaintenance

A stepped area chart rising from a point marked 'ship' and continuing upward across time

"We'll just add it" is one of the most expensive phrases in a planning meeting, and it rarely gets treated that way. The build cost — the part that shows up on the estimate — is a down payment. The rest of the bill arrives quietly, every quarter, for as long as the feature exists.

What a shipped feature costs after launch

The launch is the cheap part. Afterwards, the feature lives in:

a dependency you now have to keep patched, forever, including the day it ships a breaking change
an extra branch every future change has to be checked against
a test suite that got slower, so every CI run for every unrelated change now costs a little more
a config flag nobody remembers the meaning of
a slice of the on-call surface — one more thing that can page someone at 3 a.m.
documentation that is now subtly wrong
and a load on the one person who understands how this feature interacts with the other forty

None of that was on the original estimate, because the estimate was for building it, not for living with it.

Why the cost stays invisible

The build has a line item, a ticket, and a demo. The maintenance has none of those. It shows up spread thinly across every subsequent sprint as "things feel slower than they used to," and it never gets attributed back to the feature that caused it. So the ledger only ever records the upside. Nobody writes "this feature cost us six per cent of our velocity for three years" next to the launch announcement.

The part that compounds

Features are not independent. Ten features are not ten units of complexity; they are the interactions between them. Every new one has to be correct against all the ones already there, and that surface grows faster than the feature count. This is why a team of the same size ships more slowly as the product grows, even when everyone is working just as hard — the same reason cloud convenience compounds and the same reason maintenance, not authorship, was always the expensive part.

What actually helps

Say no more, and mean it. Most feature requests are reasonable in isolation. The cost is never one feature; it is the hundredth.
Give features an expiry review, not just a launch. Six months after shipping, look at whether anyone uses it. Put that review on the calendar at launch time.
Measure usage and delete from the bottom. The features in the lowest few per cent of use are almost pure cost. Removing them is a real improvement, not housekeeping.
Treat "remove this" as a legitimate roadmap item. A smaller surface is faster to change, cheaper to secure, and easier to hold in one head. That is worth planning time.

The AI wrinkle

Now that generating a feature is close to free, the ratio gets worse, not better. The constraint was never the typing — it was living with the result. Cheap generation just means more things to maintain, more surface to secure, more interactions to keep correct, unless someone is still doing the unglamorous work of saying no.

Where I've landed

Some of the most valuable work I have done for clients was a delete — removing three or four features nobody used and reclaiming the speed and the attention they were quietly consuming. Nobody puts "removed four features" in a case study or a launch post. It is often the change that made the next year of work possible anyway.

FAQ

Is deleting code a good use of engineering time?

Often it's the highest-leverage use. Removing an unused feature reclaims the maintenance, security, testing, and cognitive cost it was consuming every sprint — which usually outweighs the one-time effort of removing it. It only looks unproductive because the savings are spread out and invisible.

What is the real cost of a software feature?

The build is a small fraction. The ongoing cost is dependency upkeep, an extra case for every future change to consider, slower tests, a larger on-call and security surface, stale documentation, and the mental load of one more thing interacting with everything else — paid every quarter for as long as the feature exists.

Why does development slow down as a product grows?

Because features interact. Each new one must be correct against all the existing ones, and that interaction surface grows faster than the feature count. The same team ships more slowly over time even working just as hard, because complexity is compounding underneath them.

How do you decide which features to remove?

Instrument usage, then look at the bottom few per cent. Features almost nobody uses are close to pure cost. Combine the usage data with a scheduled review — set six months after launch — so removal is a normal decision rather than something that only happens in a crisis.

Does AI make feature bloat better or worse?

Worse, if nothing else changes. Cheaper generation removes the friction that used to limit how many features got built, but it does nothing about the cost of maintaining them. More features generated means more surface to keep correct and secure unless someone is still gatekeeping scope.

What is feature sunsetting?

Deliberately retiring a feature that no longer earns its keep — announcing it, migrating or notifying the few users who rely on it, and removing the code, tests, and infrastructure behind it. Done routinely, it keeps the maintenance surface from growing without limit.