Symphony Apps Development logo — teal interlocking S monogram beside the studio wordmark
All writing

The cost of a feature nobody removes

Every product we inherit carries a set of features with almost no users and a real maintenance bill. Deleting them is engineering work worth scheduling.

Category
Process
Reading time
5 min
Published
03 Apr 2026
Topics
Process, Engineering, Delivery

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.

Tell us what you’re trying to ship

A first call is thirty minutes and costs nothing. Bring the problem, not a spec — working out what to build is the part we are good at.

Or email office@symphonyapps.ro. We reply within one business day, in English or Romanian.