Almost nothing starts as bloat.
A few things are born dead. A feature built for one demo, or for a single slide in a deck. Those are rare. Most of what you would cut today was obviously worth adding on the day it arrived. Someone made the case and someone said yes, because it solved a real problem for the company you were then.
That is the thing people miss about bloat. It is rarely made of bad decisions. It is made of good ones that outlived their reason.
Let me follow one part of a product from the day it arrives to the day it becomes dead weight. Nobody chooses any step along the way.
The example is invented, but most products have one like it. Say it is a verification step early in your signup flow. On day one it is Core, and everyone agrees. The company is new and nobody trusts you yet. Fraud is a live threat, and the step catches real bad actors before they get in. It has an owner and a reason, written down in the launch notes. Nobody would think of cutting it.
Then time passes. You build proper fraud detection. The brand earns trust. The kind of user who used to slip through now gets stopped earlier, automatically, by systems that did not exist when the step was built. The reason for the step has quietly moved somewhere else.
The step does not move with it. It sits where it always sat, adding friction to every signup and catching almost nothing.
Here is the part that matters. Hardly anyone notices, because hardly anyone is looking. The step was never in question. It is just how the product works. New engineers inherit it and assume it earns its place. In a working product, most things look necessary until someone tries to remove them.
That is the life of a part. Nobody kept it. It just stayed.
Core by decision, bloat by drift.
Now the thing that makes this a law and not just a sad story. Not a law of physics. A law of defaults: leave a system alone, and this is the direction it drifts. Things do get removed. But removal does not happen on its own. Something has to force it.
Adding has a moment. There is a decision, an owner, a reason written down, a ticket, a launch. Adding is an event, and events get scheduled, argued about and recorded.
Removing has none of that. Nothing on the calendar says look at the verification step again. No customer asks you to take away something they never see. Few engineers are measured on what they deleted. Removal has no natural trigger, so it mostly does not happen. Parts arrive with a ceremony. They leave, if they leave at all, only when someone goes out of their way to remove them.
So the system fills up. Value keeps moving, the parts it used to live in stay behind, and very little leaves on its own. That is the drift. By default it runs from Core toward Bloat, because the default is to keep.
Underneath the drift is a matter of practice. A team has two muscles, and they are not the same size, because it only ever works one of them.
The addition muscle gets used every sprint. Deciding what to build, scoping it, shipping it. Most teams are strong at addition. It is most of the job.
The removal muscle is weak. Ask a team when it last took something out of the product on purpose, and most cannot say. It stays weak because removal asks a harder question. Addition asks: would this help? That is easy and optimistic, and the answer is usually yes. Removal asks: is this still worth what it costs? That means judging something that already exists, that a colleague built, and that might matter in a way you cannot see. The question feels risky, so it rarely gets asked. A muscle you never use does not get stronger.
The usual response, once a team feels the weight, is a clean-up. A dedicated sprint, or a yearly hunt for dead code and unused features.
It rarely holds. The clean-up is not wrong. It treats a constant force as a one-time event. Drift is not a mess you tidy once. It is a current that runs every day, and whatever you clear this quarter starts filling up again the next. How to build a steady counter-force is its own subject, and I will come to it.
So if parts drift from Core toward Bloat by default, and the drift runs one way, the dangerous part of your system is not the thing everyone already knows is dead. Dead things are the easy case. Sooner or later someone notices and removes them.
The dangerous part is the one still wearing the Core label long after the value has moved out. It looks essential. It sits in the deck and gets defended in planning, because it was Core once and nobody recorded the day it stopped being Core. It has all the status and none of the value.
That thing has a name, and it is the most expensive object in a product. That is where I go next.
Cases in this series are composites. The patterns are real, the companies are not.
The full Core and Bloat™ method, four boxes and all, sits at dirkbauer.com/core-and-bloat.html.