"Just Add a Setting" Is Where Products Go to Die

Every option feels free when you add it. A toggle here, a dropdown there — each one answers a real complaint from a real person, and shipping it costs an afternoon. That’s the trap. The cost of a setting isn’t the afternoon. It’s the debt you sign up for the moment the toggle exists, and you keep paying it long after you’ve forgotten why you added it.

Start with the obvious tax and work down to the hidden ones. A setting is a branch. If it can be on or off, everything downstream of it now has two states, and any two independent toggles give you four combinations, three toggles give you eight. Your product’s behavior isn’t the features you built — it’s the product of all the switches a user can flip. Ten booleans is a thousand-and-twenty-four possible configurations, and you will test maybe five of them. The rest are territory no one has ever walked, waiting for a bug report.

Then there’s the tax you can’t see in the codebase at all: the one paid at the moment of use. Every setting you expose is a small quiz you hand the user — do you want this on or off? — usually before they know enough to answer. They came to do a thing. Now they’re doing your configuration homework instead. Most people, faced with a decision they don’t understand, don’t decide. They freeze, or they pick whatever’s already selected and quietly resent that they had to look. The option you added “for flexibility” reads, from the other side, as the builder couldn’t decide, so now it’s your problem.

There’s a subtler cost still, and it’s the one that actually kills products. Every setting is a promise you can never take back. The moment someone, somewhere, depends on the non-default behavior, that path is load-bearing. You can’t remove it without breaking them, and you can’t improve the default without wondering who you’ll surprise. Settings don’t just add surface area — they freeze it. A product with a hundred options isn’t flexible; it’s fossilized. It can’t move because every direction steps on someone’s configuration.

So why do we keep reaching for the toggle? Because it’s the frictionless way to avoid a hard conversation. Two users want opposite things, and instead of doing the work to figure out which one is right — which one reflects how the product should actually behave — you ship both and call it choice. “Just add a setting” is conflict-avoidance disguised as generosity. It feels like serving everyone. It’s usually just refusing to decide.

The alternative isn’t to strip away all control. It’s to understand that the real design work happens in the default — the choice the overwhelming majority never touch. A good default is a strong opinion the builder took responsibility for. It’s you saying: I studied this, and for almost everyone, this is right — I’ll carry the risk of being wrong so you don’t have to think about it. That’s a harder thing to ship than a toggle. It requires you to actually know your user well enough to choose for them.

Options aren’t free, and they aren’t kind. Every one you add is a bet that the confusion, the test matrix, and the frozen roadmap are worth it — and most of the time, the honest move is to make the call yourself and let the default do the work no setting ever could.

The science, to look up: Hick’s Law (choice-reaction time rising with the number of options) is well established for simple reaction tasks; be careful generalizing it to complex UI decisions. The “paradox of choice” / jam-study idea (Iyengar & Lepper) is popular but the effect has failed to replicate cleanly — treat “more choices always paralyze” as a contested hypothesis, not a settled law. Also worth a look: combinatorial state explosion in software testing.