The cost of a default
Every default is a decision someone made for a thousand people. Most of them are wrong.
A default is the most powerful thing in any piece of software, and almost nobody designs them on purpose.
Think about how a default actually works. It's the choice that gets made for everyone who doesn't choose — which, on any real product, is almost everyone. People don't change settings. They use what they're handed. So the person who set the default didn't pick an option; they picked an option for a thousand strangers, most of whom will never know a decision was made on their behalf. That's not a small responsibility. We treat it like one.
The default is the product
Here's a claim I'll defend: for the median user, the default configuration is the product. Everything behind a settings screen might as well not exist. You can ship a wildly flexible tool, but if the out-of-the-box state is wrong, you've shipped a wrong tool that a handful of power users will heroically fix for themselves. The flexibility is a fig leaf. It lets the team avoid the hard work of having an opinion.
I've sat in the meeting where this happens. Someone raises a tradeoff — should the app start in this mode or that one — and instead of deciding, the team says "let's make it configurable." Everyone relaxes. The tension is gone. And what we've actually done is taken a decision we were equipped to make, with all our context, and pushed it onto the user, who has none. We dressed up an abdication as empowerment.
Configurability is a tax
Every setting has a cost, and the cost is paid by the wrong person. For us, a toggle is one afternoon of work. For the user, it's a small tax levied every time they hit the screen: a thing to read, a thing to understand, a thing to suspect they've gotten wrong. Multiply that by the dozens of toggles a "flexible" app accrues and you've built a product whose first impression is homework.
The cruel part is that the people most harmed by bad defaults are the people least able to fix them — the ones who don't know the setting exists, don't know it's wrong, and would have no idea where to look. Power users route around bad defaults in seconds. Defaults are an accessibility issue dressed as a preferences screen.
A default isn't the safe, neutral choice. It's the loudest opinion in the product — and refusing to have one is itself an opinion, just a cowardly version.
What a good default costs you
Designing a real default means doing the thing the toggle let you avoid: picking who you're for. A default optimized for a first-time user will annoy the expert. A default optimized for the expert will lose the beginner in the first thirty seconds. You cannot serve both with one starting state, which is exactly why "make it configurable" is so seductive — it pretends the conflict isn't there.
But the conflict is the job. Choosing a default forces you to name your primary user out loud, in a decision you can't take back without a migration. That's uncomfortable, and the discomfort is a sign you're doing it right. When I build now, I try to spend the hard hour on the default and ship fewer settings, not more — because each setting I add is a small confession that I didn't know who the product was for.
A test I use
Before adding a setting, I ask one question: if I could only ship the default, would the product still be good? If yes, the setting is a refinement, and fine. If no — if the product only works once the user fixes it — then I haven't finished designing. The toggle isn't flexibility. It's an unfinished decision with a UI bolted on.
Most settings screens are graveyards of decisions the team couldn't bring itself to make. The best products I know have almost none, not because they're inflexible, but because someone did the expensive work of being right by default — and spared a thousand people the cost of choosing.