Building for 23 million users taught me to delete things

Somewhere in an old roadmap from the US fintech I used to build for, there’s a feature that took four engineers three weeks, shipped to all 23 million users, and got clicked by maybe a few hundred of them in the first month. Nobody killed it for a year. I approved that roadmap. That one still bothers me.

At that kind of scale, every feature you ship is a tax. Support has to learn it, engineers have to carry it through every future release, and somewhere on a screen a user has to look at a button that isn’t for them before they find the one that is. That cost never shows up in the sprint estimate. It shows up eighteen months later as “why does this take so long to change” and nobody remembers why the thing was built in the first place.

The tax nobody puts in the sprint estimate

Product reviews measure shipping, not removing. You get credit for the button, not for the empty space where a confusing button used to be. I sat through enough of those reviews to notice that deleting something was never even on the whiteboard as an option. It was always add, adjust, or leave alone.

Part of it is fear, especially with money involved. Someone somewhere might depend on that one toggle, so nobody wants to be the person who breaks their workflow for a rounding error in the metrics. I’m not fully sure this is a fintech-only thing, but the stakes make people extra cautious about touching anything that’s already live, so the pile just grows quietly in the background while everyone’s busy shipping the next thing.

$7 to $20 without shipping a single new feature

The clearest proof I have of this is a paid product I ran that went from $7 to $20, a 192% increase, without adding one new capability. We took things away instead.

There were settings that existed because one customer asked for them years earlier and nobody had the nerve to check if anyone else still used them. Turns out almost nobody did. There were three separate places in the flow where a user had to make a decision that didn’t actually matter to their outcome, and every one of those decision points was a spot where someone could talk themselves out of paying. We stripped those out, cleaned up what was left until the core job was obvious in one look, and the price increase landed because people finally understood what they were paying for. The product didn’t get smarter. It got quieter.

Why deleting is the harder skill

Adding is the safe move. You can point at the ticket and say you shipped something, and if it flops quietly nobody circles back to ask why it existed. Deleting is a bet. You’re claiming you know what doesn’t matter, and if you’re wrong, someone notices immediately and tells you about it in a very loud Slack message.

For a while I thought this came down to confidence, engineers and PMs just not having the nerve to cut things. I don’t think that’s actually it. It’s a measurement problem. If you don’t know who’s using a feature, or why, you can’t defend killing it, so it survives on inertia and gets maintained out of fear instead of purpose. The teams that delete well are the ones that actually track usage down to the feature level, not the ones with the boldest opinions in the room.

At the studio now, this is basically the first thing we check on any audit: not what’s missing, but what’s already there that’s quietly costing someone attention. Half the time the fix isn’t a new build at all. It’s a smaller product hiding inside the one that already shipped.

We still have three things on the current backlog we’re arguing about cutting. I don’t have a clean answer for at least one of them yet.