On removing features
Adding a feature is easy to announce. Removing one is hard to explain. So most products do the first and never the second, and over a few years they become unmaintainable monuments to every good intention anyone ever had.
We try to do the harder thing.
For a small studio, this isn’t a matter of taste. We maintain a lot of apps across a lot of platforms — iPhone and iPad, Android, Windows, browser extensions — with a team that fits on one video call. Every feature we keep is a feature we test on every release, describe in every store listing, translate into every language and answer questions about. That cost doesn’t go away because a feature was a good idea once.
How we decide
A feature comes up for review when its maintenance cost is consistently bigger than its usage. We look at three things: how many people open it in a given month, how often it’s the source of a support ticket, and how much it blocks us from doing other work.
The third one is the easiest to underestimate. A feature can be used by a reasonable number of people, generate almost no support email, and still be the reason a redesign takes twice as long. An export format nobody asks about can quietly dictate how the whole data model is shaped. When we find one of those, we have to ask whether the feature is worth everything it’s preventing.
What we don’t do is remove things because they’re unglamorous. A plain switch that people rely on every day is worth more than a clever screen that gets opened once out of curiosity.
How we remove it
Announce in advance — usually two full release cycles. Give users a path out: an export, a setting that’s migrated cleanly, instructions to do the same thing with the platform. Reply to every email. Then ship the smaller, cleaner app.
The path out matters more than the announcement. Most people don’t read release notes, so the first time they notice a removal is when they go looking for the feature. We want that moment to land on a clear explanation inside the app, not on a missing button. If the feature held any of their data, that data has to leave with them in a format they can actually open somewhere else.
What we got wrong
The mistake we’ve made is removing something too quietly. It’s tempting to think a feature with low usage won’t be missed, and to drop it in an update without much fuss. The people who did use it noticed immediately, and they were right to be annoyed: from their side, the app simply got worse overnight with no warning. Small audiences still deserve the full process.
We’ve also learned not to over-explain. A removal note that runs to several paragraphs of justification reads like guilt. Now we say what’s going, when, why in a sentence or two, and what to do instead.
Why it’s worth it
Every removal makes the next decision easier. A smaller app is faster to test, easier to bring to a new platform, and simpler to describe honestly in a store listing. It’s also easier to use, which is the point.
The apologetic part is letting down the people who loved the feature. The unapologetic part is that the app is better for everyone afterwards, including most of them.