FEATURE BLOAT · PRODUCT AND PROCESS
More features = more mess
Nobody sits down and decides to build a complicated system. Complicated is what happens after you say yes thirty times in a row to requests that each sounded small and sensible on its own. And when someone opens the system in the morning and does not know where to start, the last feature added is not the culprit. The sum is.
“Just one more small button”
Almost every system that got bloated did so in good faith. Someone asked for another report, someone else asked for another field on the form, and at the next meeting an idea came up for a screen that would bring the two together. None of those requests is unreasonable, and each has a real person behind it with a real need.
The problem is that each request is weighed on its own, and nobody weighs the sum. The question that gets asked is “how long will this take to build?” — and when the answer is “two days”, the request is approved. The question nobody asks is “what does this do to the system we already have?”, and that is the expensive one.
Because a feature is not an item you place on a shelf beside other items. It goes inside something that already exists, moves things around and connects to them. Add it to a system that is already crowded and what breaks is not the new feature — it is the ability to find the old ones.
The four prices of a single feature
Screen space. A screen is a finite resource. Every new button lowers the ratio between “what I do every day” and “what can be done here”. At some point the everyday action stops standing out, and whoever opens the screen has to look for it. They will not say the system is crowded; they will say it is complicated.
A decision. Every option on display has a cost even for the people who never choose it. The longer the list of options, the longer it takes to decide — a principle known in interface design as Hick's law. Three seconds of hesitation on an action performed forty times a day is not negligible, and worse: it adds up to a feeling that the system is a burden.
Bugs. Features do not add up — they multiply. Two independent toggles create four possible states; ten toggles create more than a thousand. No team tests a thousand states after every change, so the more capabilities there are, the higher the odds that a change in one corner breaks something in another. That is why in older systems “every fix drags another fix”.
Maintenance. Code written once is maintained forever. It has to keep working after an operating-system update, after a change at an external service, after a payment provider is swapped out. The screen built “just in case” and never opened is still tested, still updated and still costing money — a subject we set out in the article on what it costs to run a website or app.
The mess does not live in the code — it lives with the user
The real price of a bloated system is not technical. It sounds like this: “I'm just not good with computers.” That is almost never true. The person saying it runs a phone, books appointments online and moves money in an app — they have simply run into an interface that asks them to remember things instead of showing them.
And it lands precisely on the people the system matters most to. The long-serving employee who knows the business inside out, whoever runs the diary, the tradesperson who wants to finish the day rather than learn software — those are the first to drop off as more and more gets added. They do not complain; they route around it. A side spreadsheet appears, a WhatsApp group, a sticky note on the monitor. And the moment a workaround exists, the system no longer holds the truth — which is exactly the problem it was built to solve, as we described in the article on when to replace Excel with a system.
Bloat also shows up in less obvious places. On websites and web apps, every extra capability translates into more code for the browser to download and process; Web Almanac data shows the average page weight keeps growing year on year. The user experiences that as slowness, not as a surplus of features.
| What is asked for | How it sounds in the meeting | What it actually costs |
|---|---|---|
| Another field on the form | “It's one field, a minute of work” | One more question every user answers every day; a longer form that fewer people finish |
| Another report | “Let's have it, in case we need it” | A report menu you have to search through; a report nobody opens and everybody maintains |
| A setting you can switch off | “Let everyone pick what suits them” | Two different modes to support, to test and to explain over the phone |
| Another “admin” screen | “As a backup, not everyone will go in” | Permissions, testing and maintenance on something opened twice a year |
| A connection to another system | “They have an API, it's quick” | A dependency on a third party that updates without asking; a new point of failure |
How to decide what stays out
Listen to the problem, not the solution. A feature request is almost always a frustration that someone has already translated into a fix in their head. It pays to walk back: when did you last need this, and what do you do instead today. Often the frustration turns out to be solved by a small change to a screen that already exists.
Ask how many times a month. A daily action deserves a central spot. A monthly action deserves a spot you have to look for. A yearly action does not deserve software at all — better to do it by hand once a year than to maintain a screen for it forever.
Decide what comes off. The most useful rule is that every new feature entering a screen has to name what leaves it. That forces ranking, and it exposes very quickly that some requests simply are not important enough next to what is already there.
Measure before you expand. If the system is already live you can know rather than guess: what gets opened, what does not, and where people get stuck. An expansion grounded in measurement is almost always smaller than one grounded in a meeting.
And what about a system that is already bloated
Do not rebuild. That is the common and expensive reflex, and it almost always produces a new system that bloats in exactly the same way — because the problem was never the technology, it was the decisions.
Start by measuring: what is genuinely in use, and how often. Then hide rather than delete — take what is barely touched off the main screen and leave it reachable through a secondary menu. Wait a month. Whatever nobody went looking for can be removed safely, and whatever someone did look for goes back where it was.
The result is usually surprising: the same system, the same capabilities, and suddenly people manage without training. Nothing was added — it simply stopped hiding itself.
How we work with this. At appotto we build for people who do not like technology, so “no” is part of the service. In scoping we ask how many times a month each request is really needed, and what comes off the screen if it goes on. The tracking app we built for a father in his seventies, who has opened it every day for two years, survives precisely because we refused to add half the things we thought of. The same principle sits behind everything we have built: one screen that is obvious immediately, and a price fixed in advance with no surprises.
Have a system your staff route around, or a scope that has started to swell? Send us a short message about what people actually do every day — and we will tell you honestly what is unnecessary.
Frequently asked questions
Why do more features actually hurt a system?
Because every capability you add charges you in four places at once: it takes space on the screen and pushes aside what people actually do every day, it adds one more decision the user has to make, it multiplies the number of states that need testing after every change, and it stays in maintenance for as long as the system is alive. Those costs stack on each other, which is why a system with fifty capabilities is not five times more useful than one with ten.
How do you know a system has become bloated?
The first sign is that people ask each other where to click instead of simply clicking. The second is that the system needs repeat training: a new employee cannot manage alone, and someone back from two weeks away is lost. The third is that workarounds appear — a side spreadsheet, a WhatsApp group, a sticky note on the monitor — because doing it through the system takes too many steps. The fourth is that every small change breaks something else.
What do you do when staff keep asking for more features?
Listen to the problem, not to the solution they proposed. A feature request is almost always a description of a frustration, and not necessarily the right fix for it. Ask when it last happened, how many times a month it happens, and what people do instead today. Often the request turns out to be answered by a small change to an existing screen, and sometimes it turns out to be needed twice a year — in which case handling it by hand beats maintaining a whole screen for it.
Isn't simple just another word for weak?
No. A weak system is one that does not do what is needed; a simple system does exactly what is needed and does not display what is not. Cutting items from a list is easy, but deciding what stays and how it fits on one screen is the hard engineering work. The systems that look simple from the outside are usually the ones the most thought went into.
Can you remove features from a system that already exists?
Yes, and on an older system it is usually the best-value investment available. Measure what is genuinely in use first, hide what almost nobody touches rather than deleting it outright, and wait a month to see whether anyone complains. Whatever nobody went looking for can be removed safely. The system stays the same system, but it becomes usable again without training.
Sources
- Nielsen Norman Group — Hick's law — the professional account of why a user's decision time grows as more options are presented, and what that means for interface design.
- HTTP Archive — Web Almanac, page weight chapter — yearly data on how much code websites and web apps actually load, and the trend over time.
A system nobody wants to open?
Tell us what people actually do every day. We will tell you what is unnecessary, what is missing and what can be hidden — with a quote fixed in advance. First consultation free.
Email us