The changelog nobody wants to read
Open your phone's app store and check the recent updates. Most changelogs say one of two things: "Bug fixes and performance improvements" or a list of new features. Occasionally you will see something different: an update that announces it has removed something.
The reaction is almost always negative. Users who relied on the feature feel betrayed. Users who never used it feel anxious about what might disappear next. One-star reviews appear within hours. The app's rating drops.
And yet, in most cases, the app just got better.
Welltide builds PackPilot for travel packing and PawDex for pet health. Both are deliberately small apps made by a small team at Cogniq AI. Neither has been through a real post-launch removal yet, both are still young, but the same discipline already shapes what we say no to before anything ships, and it is only a matter of time before it means cutting something that did. This post explains why that is usually the right call, how to distinguish a good removal from a bad one, and why the instinct to panic is worth overriding.
Why features get removed
The feature was not earning its keep
Every feature in a shipping app carries ongoing cost. It occupies screen space. It appears in search results within the app. It needs to be tested against every other feature when anything changes. It shows up in onboarding flows or help documentation. It has edge cases that generate support tickets.
A feature that ten percent of users touch once a month might not justify the complexity it adds for the ninety percent who never touch it at all. The math is not always this clean, but the principle holds: a feature is not free after it ships. It costs something every day it exists, and the question is whether the value it provides exceeds that cost.
The feature conflicted with a better approach
Sometimes you build a feature, learn from how people use it, and realise there is a better way to solve the same problem. Keeping the old version alongside the new one means two paths to the same outcome, which confuses users and doubles the test surface.
Instagram removed its Following Activity tab in 2019. The tab showed what posts your friends had liked and who they had followed. It was a stalking tool dressed as a social feature, and it conflicted with the platform's shift toward privacy. The removal was controversial. It was also clearly the right decision, and nobody today argues for bringing it back.
The feature attracted the wrong behaviour
Some features work as designed but produce outcomes nobody wanted. A social sharing button in a private health tracker encourages people to broadcast medical data. A public leaderboard in a personal finance app creates anxiety about spending. The feature does what it was built to do, and what it was built to do turns out to be harmful.
A packing checklist is a plausible candidate for this mistake: a sharing button copied in from apps where sharing makes sense, implying that a packing list is social content when it is not. It is the kind of feature that is easy to justify in a planning meeting and hard to justify once it is sitting in the header taking up space nobody asked it to take.
The feature was added to hit a metric
This is the cynical one. A feature gets built because it drives a number, not because it helps the user. When that number stops mattering, or when leadership changes, the feature gets cut. Users who built workflows around it are left stranded.
This happens most often with free features that get moved behind a paywall. The feature was never sustainable at its price point (free), and removing it is how the company corrects the mistake of offering it in the first place. The user is not wrong to be upset. The company is not wrong to need revenue. Both things are true, and the user still loses.
Technical debt accumulation
It is not just about screen space or user interfaces. Every line of code added to support a feature is a line of code that must be maintained, refactored, and updated. In software engineering, this is known as technical debt. When you have thousands of lines of code dedicated to an underused feature, that code still has to be compiled every time you build the app.
If third-party API dependencies are involved (like a mapping library or weather service), you are also at the mercy of their updates. When they change their API signature or deprecate a version, you must stop what you are doing and rewrite your implementation just to keep the existing feature working. By removing the feature, you eliminate that entire dependency tree and the maintenance burden that comes with it, freeing up developer hours to focus on core performance.
How to tell a good removal from a bad one
Not all removals are equal. Here is a framework for evaluating them:
| Signal | Good removal | Bad removal |
|---|---|---|
| Explanation | The company explains what was removed, why, and what replaces it | The feature quietly disappears or the changelog says "improvements" |
| Paywall | No paywall appears where the feature used to be | The feature reappears in a premium tier |
| Data | Your data is preserved or exportable | Your data is inaccessible or deleted |
| Replacement | The remaining app handles the same job more clearly | Nothing replaces it and a workflow breaks |
| Pattern | The app has a history of thoughtful, explained changes | The app has a history of removing things users like |
A company that removes a feature and explains the reasoning publicly is doing something hard and honest. A company that removes a feature and pretends it never existed is telling you something about how it views the relationship.
For a broader look at manipulative app design, see dark patterns in apps: a field guide.
Where we apply this before it ever becomes a removal
We should hold ourselves to the same test. The honest version: neither PackPilot nor PawDex has been through a real post-launch removal, because both apps are young enough that most of this discipline has happened earlier in the process, as a decision never to ship the feature at all.
A streak counter is the clearest example. It is, by a wide margin, the single most effective feature available for raising daily opens. We know that, and neither app has one. Not because we built one, watched it work, and cut it. Because we ran it through the table above before writing a line of code: would it make the app clearer, or would it just make it louder. For PawDex specifically, a streak converts "did you check on your dog today" into "did you protect your streak today," which is a worse question. The full argument is in why app streaks work and why we do not use them.
The same reasoning has kept a social feed and engagement-driven notifications out of both apps. A feed would have made both products look more active on a screenshot. It would also have meant building for an audience, not a job, and neither app is trying to be a place people visit, only a tool they open when something is actually due.
None of this makes us special. It just means the interesting test has not arrived yet. The genuinely hard version of this discipline is not saying no before something ships. It is admitting, after something has shipped and has real users attached to it, that it should not have. We have not faced that yet, and when we do, this is the standard we are writing down in public so we can be held to it: an explanation, no paywall where the feature used to be, and your data intact regardless of what we decide.
The 'Yes' is cheap, the 'No' is expensive
In product management and app design, it is incredibly easy to say yes. A user emails asking for a weight tracking line graph. An advisor suggests adding a calendar invite integration. A developer proposes a quick widget. Say yes, write the code, ship it, and everyone is happy in the short term. The user feels heard, the advisor feels smart, and the team feels productive.
But saying yes is a cheap decision with long-term consequences. The true cost of that yes is paid over the next five years in maintenance, complexity, and slow updates.
Saying no, or saying "we are removing this," is highly expensive in the short term. You have to deal with the immediate disappointment of users, answer support queries, and explain your reasoning. But it is cheap in the long term. It keeps the codebase clean, the interface focused, and the team agile. A product is defined by what it excludes, not what it includes. If you cannot say no to a feature request, or if you cannot bring yourself to deprecate a feature that is no longer working, you do not own a product—you own a pile of features that are slowly sinking under their own weight.
The psychology of loss
Users react to removal more strongly than to addition, and this is not irrational. It is loss aversion, the same mechanism that makes app streaks so effective. Losing a feature you have feels worse than gaining a feature you do not have yet.
This creates a ratchet effect. Adding a feature is easy. Removing it is painful. So features accumulate, each one making the next removal harder. This is how apps that started as simple, focused tools end up as cluttered platforms that nobody can explain in a sentence.
The ratchet only breaks if someone is willing to absorb the short-term backlash in exchange for long-term clarity. This is why the best app updates are often the ones that say "we removed X" rather than "we added Y."
For the full picture of how this accumulation works, see why apps get worse over time.
What to do when your favourite feature disappears
You do not have to accept every removal quietly. But there is a difference between a useful response and an angry one.
Check the changelog or blog. If the company explained the removal, read the explanation before reacting. You might disagree, but understanding the reasoning puts you in a better position to give useful feedback.
Check if your data is safe. If the feature stored data, confirm that the data is still accessible or exportable. This is the one non-negotiable. A feature removal that destroys user data is always wrong, regardless of the reason. For more on this, see what happens to your data when an app shuts down.
Give it a week. The initial reaction to any interface change is negative. After a week of use, you will have a clearer sense of whether the removal actually affects your workflow or whether you are reacting to the change itself.
Leave specific feedback. If the removal genuinely broke something you relied on, describe the workflow that no longer works. "I used feature X to do Y, and now I cannot do Y" is actionable feedback. "Bring back X" is not, because it does not tell the developer what problem X was solving for you.
What we are committing to before we need to
It would be easy to write a piece about the virtue of removal and quietly leave ourselves out of the hard part, since neither app has had to prove it yet. So here is the specific commitment, dated, so it can be checked against whatever we actually do later.
If we ever remove something from PackPilot or PawDex that people are actively using, three things hold. We will say so, in the changelog or the blog, in plain language rather than "improvements." We will not put the same capability back behind a paywall. And your data stays yours regardless of what happens to the feature that created it, which is the one item in this piece with no exceptions. We wrote a full breakdown of what that promise should look like in practice in what happens to your data when an app shuts down.
That is a low bar. Most of this article has argued it should be the default, not a virtue. The reason to write it down now, before it is tested, is that a promise made in advance of the situation it covers is worth more than one made in the middle of it, when explaining a cut is also convenient.
The update worth trusting
The app update that adds twelve features is easy to celebrate and hard to maintain. The app update that removes two features is hard to celebrate and easy to maintain. Over a long enough timeline, the second app is the one that still works.
When you see a changelog that says something was removed, do not panic. Read the explanation. Check your data. Give it a week. And consider the possibility that the app you are holding just got better by becoming less.
Welltide builds apps that do one job each. PackPilot packs your bag. PawDex tracks your dog. If something in either app is not earning its keep, we will cut it, explain why, and trust that a smaller, clearer tool is worth more than a bigger, busier one.
For help deciding which apps deserve your attention in the first place, see how to choose an app you will still use in a year.
Related Reading
- Why Apps Get Worse Over Time explains the feature creep dynamic that makes removal necessary.
- Why App Streaks Work, and Why We Do Not Use Them is the fuller argument for why neither of our apps has one.
- Dark Patterns in Apps: A Field Guide covers the design tactics that feature removal sometimes corrects.
- What Happens to Your Data When an App Shuts Down covers the non-negotiable: data safety during any product change.
Frequently Asked Questions
Usually because the feature was underused, created maintenance burden, confused new users, or conflicted with a better approach. Occasionally because of a licensing or API change outside the developer's control. The reason matters more than the act.
No. Removal is good when the feature was clutter and its absence makes the remaining tools clearer. Removal is bad when the feature had active users and was cut to push them toward a paid tier, to reduce server costs, or because the company stopped caring about that audience.
Ask whether the remaining app is simpler and whether the company explained the change. Good removals come with a clear reason, a migration path if data is affected, and no paywall where the feature used to be. Bad removals come with silence, a new subscription prompt, or a vague note about focusing the experience.
Not yet, in the sense of shipping something and later cutting it. Both apps are young, and so far the discipline has been declining feature requests before they ship rather than removing what already shipped. Neither app has a streak counter, a social feed, or engagement-driven notifications, not because we built and cut them, but because we ran each one against this same framework before writing any code and it failed.
Because the user chose the app partly because of the feature that was removed. The removal feels like a broken promise, especially if they paid for the app. The frustration is legitimate even when the removal is the right decision, which is why good teams explain cuts publicly.
Feature creep is the gradual accumulation of capabilities until an app becomes slow, confusing, and difficult to maintain. Each individual addition seems small, but the total weight compounds. Removing features is one of the few ways to reverse it.