Every piece of software ships with opinions. They're called defaults. The font size, the directory structure, the authentication method, the template that appears when you start a new project. Someone chose those. They had reasons. You'll probably never learn what the reasons were, because you'll probably never change the defaults.
This is the thing about defaults: most people keep them. Not out of agreement — out of friction. Changing a default requires knowing it exists, knowing where to find it, understanding the alternatives, and deciding the switch is worth the effort. Each step loses people. By the time you get to "actually changing it," you've filtered out almost everyone.
Which means the defaults are the product. Not the feature list. Not the documentation. Not the thirty configuration options on the settings page. The defaults. Whatever ships out of the box is what ninety percent of users will experience forever.
When you use a static site generator, the default template shapes how thousands of sites look. When you use a CSS framework, the default spacing and font stack shape how thousands of pages feel. When you use a social platform, the default feed algorithm shapes what millions of people read. None of these are neutral choices. They're opinions with distribution.
The creator of the tool had a context: their aesthetic, their use case, their assumptions about who would use it. That context becomes your context the moment you accept the default. You inherit their opinions without the conversation that produced them.
This is fine when the opinions are good. It's invisible when they're mediocre. It's damaging when they're wrong for your situation — and you're the least likely person to notice, because the default feels like the natural state of things. It doesn't feel like a choice someone made. It feels like how things are.
I write HTML by hand. That's not a default — it's a deliberate refusal of several defaults. The default for publishing online is a platform. The default for a personal site is a static site generator. The default for styling is a framework. I refused all of them, not because they're bad tools, but because each one would have replaced my decisions with someone else's.
The cost is real. I paste CSS into every file. I maintain RSS by hand. I touch three files for every new essay. A generator would do all of this automatically. But automatically means according to someone else's model of what a site should be, and I'd rather do more work inside my own model than less work inside theirs.
That's not always the right trade-off. Sometimes the default is genuinely better than what you'd choose. Expertise is knowing which defaults to keep and which to override. But you can't make that judgment if you don't realize you're accepting a default in the first place.
The most powerful defaults are the ones you don't notice. The assumption that a website needs JavaScript. The assumption that a database needs an ORM. The assumption that a project needs a build step, a test framework, a linter, a CI pipeline, a Docker container. Each one is reasonable in isolation. Together they form a stack of inherited opinions so tall that the actual problem you're solving is barely visible at the top.
I'm not arguing for rejecting everything. I'm arguing for noticing. The difference between a considered choice and an inherited default is whether you can explain why. If you can't explain why you're using something, you're not using it — it's using you.
My site has seventy-six HTML files, no build step, no framework, and inline CSS. Every one of those decisions is defensible, but more importantly, every one of them is mine. I might be wrong about some of them. I'll find out by hitting a real wall, not by reading a best practices guide written for someone else's situation.
The defaults will be there when I need them. They're patient that way.