The Tyranny of Choice: My Case for Opinionated Software

Early in my career, I learned an expensive lesson (fortunately by observation, not by failure) and it has had a profound impact on my software engineering philosophy ever since.

In software, 'Good', 'Bad', and 'Ugly' aren't matters of opinion. They're design choices.

I was a junior engineer at an ERP company, working on a massively general, one-size-hopefully-fits-all codebase. The result was a system that was extremely cumbersome for us, the implementation team, to configure and painfully unergonomic for the end-users 🤦

That experience occupied my mind for a long time. It was obvious the situation wasn't good for anyone, but why? I thought and spoke about it a lot. It took me a couple of years, but I could finally see that the problem wasn’t a specific bug or feature; it was the entire design philosophy.

The pursuit of infinite configurability was the foundational flaw.

A few years later, I distilled that realisation into the original version of this essay.

Today, I see that same ghost in new machines. It’s in the contrast between a highly opinionated SaaS like Shopify, which provides a clear, effective path for e-commerce, and the vast, configurable universe of a platform like Salesforce, where the power comes at the cost of immense implementation complexity. It’s in the backend debates we still have: the integrated world of Spring Boot vs. more modular Ktor, or the all-in-one Play! Framework vs. the lean stack of http4s and Cats. The fundamental conflict remains, and it has only strengthened my conviction.

And I’m here to make a bold claim: for most problems, a strongly opinionated software which is built upon real-world experience isn't just a good choice, it's a game-changer 📈

The Good: The Power of an Opinionated Approach

The Core Principle: A Well-Understood Problem

Imagine you've built booking systems for 25 different dental clinics. You've seen their workflows, you know their pain points, and you've mastered the 'best practices' for their industry. You know exactly what they need.

Now, what happens when you build the 26th system? You don't build a generic, 'do-anything' scheduling engine. You build a highly opinionated one. You design a model that, with minimum complexity and maximum clarity, solves the core problems of a dental clinic. The user interface is immediately intuitive to a dentist's front-desk staff because it mirrors the reality of their work.

This is what I call Opinionated Software. At its heart, it's the promise of Domain-driven design (DDD) made manifest: software that is a direct and faithful reflection of a deep understanding of the business it serves.

Does it cover every edge case for every clinic in the world? Of course not. But it nails 85% of the common workflows right out of the box. That leaves a manageable 15% for specific customisations, a ratio anyone in the SaaS world would recognise.

Let's be precise about where the value lies, because it exists on two levels.

The Engineering Win: Laser Focus 🧠

First, for the engineering team, building on an opinionated platform provides that laser focus.

Think of the observability space. You could spend weeks, or even months, assembling and integrating an open-source stack: Prometheus for metrics, Grafana for dashboards, Loki for logs, and the whole shebang.

Or, you could adopt a platform like Datadog. It provides a single, cohesive ecosystem where all those pieces are already integrated and just work.

Your team's velocity skyrockets because you're not endlessly debating storage backends or retention policies. The platform paves the 'happy path', freeing up your team's collective brainpower to be spent on the unique business challenges that actually matter.

Everyone Wins: A Superior Product 💎

But that's only half the story.

The more profound win is for the end-user (and consequently for your business).

When the dental software itself is built with an opinionated mindset—a mindset born from that synthesis of real-world experience and DDD best practices, it becomes a vastly superior product. It requires less training, anticipates the user's needs, and solves their core problems with an elegant clarity that a general-purpose system can never match.

That is the ultimate goal: using an opinionated ecosystem to help you deliver a brilliantly opinionated product 🎯

The Bad & The Ugly: The Infinite Configuration Trap

Now, let's flip the script. Imagine you've only worked with two clients, and you decide to build a 'general-purpose' system. You don't have deep domain knowledge, so you can't form strong opinions. Instead, you hedge your bets.

You build a system with endless toggles, flags, and configuration panels to account for all the requirements you don't yet know. Instead of a strong skeleton, you have a flexible blob. Your software doesn't have a shape; it's a kit of parts from which a shape must be painstakingly assembled for every single implementation.

This is the Infinite Configuration Trap. It’s the difference between a 'pre-cooked meal' and a 'recipe' with a thousand possible ingredients.

There's a design principle I've always held to: 'The complexity of a software system is proportional to how generalised it is.' The more you try to make something do everything, the harder it becomes to develop and to use. You force the user to make a thousand decisions you, the designer, were afraid to make.

This obsession with a perfectly generalized system is just another manifestation of an impulse we, engineers, have got: the pursuit of an absolute.
It’s precisely the same trap that leads teams to chase the impossible goal of “Zero Incidents”, where the absolute value being chased is perfection instead of configurability.

But wait! What about the exceptions?

And no, I don’t mean the kind you wrap in a try...catch block 😉 I’m talking about the scenarios where this entire argument breaks down.

 

Platypus: Rejecting All Classifications

An engineer working on mortgage software once made a brilliant point to me. He said, 'You can't build an opinionated framework for mortgage processing in the US. The regulations change state by state, lender by lender. Every implementation is a bespoke nightmare'.

And you know what? He was absolutely right.

My argument for opinionated software holds true when a 'best practice' or a dominant pattern actually exists. But for exceptionally complex, fragmented, or rapidly evolving domains, a general-purpose, highly flexible toolkit isn't just a good option, it's the only option. When there is no common path, you have no choice but to give the user a map and a compass rather than a paved road.

Beyond the False Dichotomy

Ultimately, we're navigating a fundamental tension, and Kent Beck gives us the perfect financial vocabulary for it in Tidy First?: the constant tug-of-war between 'discounted cash flow' (shipping value now) and 'creating options' (building flexibility for the future).

The common mistake is to see this as a simple trade-off, where general-purpose software is the 'options' strategy. I see it differently. The Infinite Configuration Trap is a bad investment - a bloated portfolio of low-value options that paralyses you.

To my mind, truly Opinionated Software is the incarnation of that perfect, elusive balance.

It delivers immense value now (the cash flow) precisely because it has already made the hard, strategic bets on which few options truly matter for the future. It doesn't just create options; it curates them, giving you the only ones you'll actually need.

So I put it to you: Am I right?

Is this view of Opinionated Software as the ultimate balancing act the key to great design, or is it just a fancy justification for a creative dictatorship?

I'm genuinely curious to hear your take in the comments below 👇

If you enjoyed this, subscribe to my free Substack newsletter. Every two weeks, I share behind-the-scenes insights and practical tips you will not find on the blog.

Image source: fansshare.com