Everyone has watched this happen
You installed something because it did one thing well. It opened instantly. You understood it in a minute.
Three years later it takes eight seconds to launch, opens on a dashboard you did not ask for, and the thing you originally came for is two taps deeper than it used to be. There is a new tab you have never opened. There is an assistant.
Nobody sat in a room and decided to make it worse. Every individual step was defensible. That is what makes this worth explaining, because the mechanism is not incompetence, and understanding it is what lets you predict which apps will survive contact with their own success.
The machinery
Growth needs somewhere to come from
A product with a defined job has a ceiling: the number of people with that problem, times how often they have it, times what solving it is worth.
For genuinely useful narrow tools, that ceiling is often modest. Once you approach it there are two options. Find more people with the same problem, which is slow and expensive. Or give the people you already have more problems to solve with you, which is fast and cheap because you already hold their attention.
The second is not a cynical choice. It is usually the responsible one, given a team to pay.
Every feature has an advocate and no opponent
Someone always wants a given feature. There is a user request, a support ticket, a competitor shipping it, a sales deal that hinges on it.
Complexity has no equivalent constituency. There is no team whose job is arguing that the app should stay small. There is no dashboard tile reading cognitive load. The costs are real and diffuse; the benefits are concrete and attributable.
In any argument between a specific benefit and a diffuse cost, the specific benefit wins essentially every time.
The metrics only see one direction
Ship a feature, watch engagement rise, call it a win. What the experiment does not measure:
- People who now take slightly longer to do the original task
- People who found the app more confusing and never said so
- The person who did not recommend it because it is harder to explain now
- The two hundred milliseconds added to launch
None of that shows up. The dashboard says the feature worked, because the dashboard can only see what it counts.
Removing is harder than adding
Suppose someone does argue for cutting. Removal produces immediate, loud, specific complaints from the minority who use the feature. The majority who benefit from the simplification notice nothing and say nothing, because an absence is not an event.
So the ratchet turns one way. This is why bloat is close to irreversible once it starts.
Why it gets slower too
Feature creep has a technical twin, usually stated as Wirth's law: software grows in size and complexity faster than hardware grows in speed.
Each release brings another analytics library, another A/B testing framework, another vendor SDK for crash reporting or attribution. Individually small. Cumulatively the reason a phone several times faster than the one you had in 2019 opens the same app more slowly.
The frustrating part is that the added weight often serves the company rather than you. Analytics, attribution, and experimentation frameworks exist to measure and monetise, not to make the app better at its job. You are carrying them at launch time regardless.
Improvement versus creep
The distinction people miss is that adding is not automatically bad. The test is what the addition serves.
| Improvement | Creep |
|---|---|
| Makes the original job faster or clearer | Adds a new job |
| Removes a step | Adds a tab |
| Fixes something people complained about | Ships something people did not ask for |
| Fewer decisions to reach the outcome | More surface to learn |
| Optional and out of the way | On by default, in the main flow |
A packing app that gets faster at producing a checklist is improving. The same app adding a travel social feed is creeping, no matter how good the feed is, because it has changed what the product is.
The honest complication: sometimes the new job is genuinely valuable and the product should expand. Photo editors that added cloud sync did the right thing. The signal is not addition, it is whether additions still serve the reason you chose it.
The four stages, and where to get off
Feature creep follows a recognisable arc. Knowing which stage a product is in tells you how much longer it stays useful.
Stage one: the sharp tool
It does one thing. It opens instantly. The interface is small enough to hold in your head. This is when people fall in love with software and it is the stage they remember for years afterwards.
Usually the product is unprofitable here, which is why the stage ends.
Stage two: reasonable expansion
Genuine gaps get filled. Settings people actually requested. A second workflow closely related to the first. The product gets more capable without changing shape, and most users experience this as improvement, correctly.
This is the best stage to be a user, and the hardest to stay in as a company.
Stage three: adjacency
The additions stop serving the original job and start serving growth. A dashboard. A social layer. An assistant. Integrations with things you do not use.
The tell is that the home screen changes. In stages one and two you land where the work happens. In stage three you land on a summary of the product itself.
Stage four: platform
The original job is now one feature among a dozen, two taps deep, maintained rather than developed. New users cannot tell what the app is for. Old users keep it out of inertia and accumulated data.
Where to get off: the transition from two to three, which is visible in release notes before you feel it in use. When the changelog stops describing improvements to the thing you use and starts announcing capabilities you did not ask for, the arc has turned.
Some products stay in stage two for a decade. Almost all of those are either profitable at a small size or funded by something other than growth.
Spotting it before you commit
Three checks, in ascending order of usefulness. Full version in how to choose an app you will still use in a year.
Read recent one and two star reviews. The phrase to search for is it was great until. Users describe feature creep more precisely than any changelog, because they feel it first.
Look at the version history. Frequent releases with vague notes such as improvements and bug fixes over many months often mean experimentation and SDK churn rather than product work.
Ask how it makes money. This predicts everything else. A subscription must justify a renewal every month, and continuous feature addition is the standard way to make a renewal feel earned. Advertising must maximise time on screen, which favours feeds and engagement surfaces. Neither is dishonest; both push in the same direction. See how free apps actually make money.
What resisting it actually costs
We build apps at Welltide, so this is a stated position and not a neutral survey.
Holding a product to its original job is not a matter of taste. It is choosing a smaller business, deliberately, with your eyes open:
- You give up the easiest growth lever. Adjacent features are the cheapest way to raise a ceiling, and declining to use them means accepting the ceiling.
- You lose deals. Someone always wants the thing you will not build, and they go elsewhere.
- You look static. A product that ships fewer, smaller changes reads as less ambitious than one shipping constantly, even when the restraint is the harder discipline.
PackPilot builds a packing checklist. PawDex keeps a record of a dog. Both are free on Google Play. Neither has a feed, and the reason is not that we have not thought of one.
The test we use is not would people use this. People will use almost anything. It is would this make the original job better, or is it a new job wearing the old one's clothes.
We will not always get that right. The point is having a question that can produce a no, because a team without one will add features until the product is unrecognisable and every step will have been justified.
The cases that resist it
Bloat is not inevitable. It is what happens by default, which is different. A handful of categories reliably stay sharp, and they have something in common worth naming.
Software with a hard external standard. A tool that has to comply with a specification cannot wander far, because the specification defines done. Nothing about a growth target changes what the standard requires.
Products where performance is the feature. If people chose it because it is fast, every addition is visibly self-defeating. The constraint is enforced by users who will leave the moment it slows down, which is a much more reliable check than a design review.
Paid-once tools with no renewal to justify. Nobody has to be persuaded monthly that it is still worth the money, so nothing has to be added to make that case. The trade is thinner funding for long-term maintenance.
Anything with a genuinely finished job. A tool that converts a file, checks a value, or completes a task has a natural stopping point built into what it does. There is no coherent way to add a feed to a unit converter.
The common factor is an external constraint that a growth target cannot override. Where such a constraint exists, restraint costs nothing to maintain. Where it does not, restraint is a continuous act of will against everyone's incentives, and will loses eventually.
Which is the uncomfortable conclusion of this piece: if you want software that stays good, look for products whose situation keeps them honest, not products whose founders currently say the right things. Intentions are not a mechanism.
Living with it as a user
Practical, not philosophical:
Delay updates on tools that already work. If an app does its job and you have no complaint, there is little upside in being first to the version that added a dashboard.
Reassess yearly. Ask whether you would install it again today. Familiarity keeps things on a phone long after they have stopped earning the space.
Check the exit before you rely on it. The cost of leaving a bloated app is entirely determined by whether you can get your data out. Check for an export function before you build two years of records.
Notice which direction it is moving. An app getting simpler is rare and worth staying with. An app that has added three tabs since you installed it will add three more.
Related Reading
- What Is a Single-Purpose App? covers the shape of software that resists this.
- How to Choose an App You Will Still Use in a Year turns the warning signs into a checklist.
- How Free Apps Actually Make Money explains the pressure behind the ratchet.
- Why App Streaks Work, and Why We Do Not Use Them covers one specific addition and its cost.
- App Store Ratings Are Broken covers how to spot this in reviews before you install.
- The App Update That Removes Features Is Usually the Good One covers the opposite side: when taking things away is the right call.
- Why Every App Has an AI Chatbot Now covers how generative chat wrappers accelerate feature bloat.
Frequently Asked Questions
The gradual accumulation of features beyond a product's original purpose, where each addition is individually justified but the total makes the product slower, more complex, and harder to use than what people originally chose.
Because growth teams are measured on engagement, retention, and revenue, and adding features reliably moves those numbers in the short term. No common metric measures the cost of added complexity, so that cost is invisible in the decision.
Improvement makes the original job easier. Creep adds new jobs. A packing app that gets faster at building a checklist is improving; the same app adding a social feed is creeping, however well the feed is built.
Often summarised as Wirth's law: software grows in size and complexity faster than hardware grows in speed. Each release adds frameworks, analytics, and features, and the hardware gain is spent on absorbing them rather than on being faster.
Rarely, because removing a feature produces loud complaints from the minority who use it while the majority who benefit say nothing. The incentives that favour adding also punish removing.
Check the version history on the store listing and read recent one and two star reviews. Complaints phrased as it was great until the update that added X are the clearest early signal available.