There are two ways to design software, and the choice between them is often made without anyone articulating it. The first consists in not taking a position: you expose options, you let the user configure, you build a tool that adapts to however each person wants to work. The second consists in deciding for them, in embodying a way of doing things, even if it means excluding others. The first approach produces software without a point of view. The second produces software with an opinion.
The hidden cost of flexibility
Software without an opinion seems generous. It offers more choices, more customization, more latitude. It promises to adapt to how the user works rather than imposing its own way. In practice, this generosity has a price that is paid three times over.
It is paid first at build time. Offering flexibility means handling combinations of scenarios that grow combinatorially with the number of options. A form with three display modes, two validation logics, and role-based permission settings does not produce six test cases but a configuration space whose edges are difficult to map. The software becomes harder to build not because each path is complex, but because the interaction between paths is.
It is paid next at setup. Configurable software requires configuration. Someone must decide how to set it up, which means understanding the available options, anticipating their consequences, and often calling in an integrator or a consultant. The time saved through flexibility by the designer is transferred as decision burden to the client.
It is paid finally at use. Every visible option in the interface is a question asked of the user, and every question consumes attention. Software that takes no position permanently delegates the decision to the person using it, including when that person has neither the context nor the desire to decide.
Opinion as an act of design
Opinionated software works the opposite way. It embeds a philosophy about the right way to handle a problem, and it enforces it. It does not ask the user how they want to organize their data, it proposes an organization. It does not present five possible workflows, it embodies one. The choices left to make are those that belong to the user, not those that belong to the tool.
At Lucca, this approach takes the form of the workflow. When a leave management module is designed, it does not expose a configurable rules engine into which each company would plug its own logic. It encodes a sequence: the employee submits a request, the manager approves, the balance updates, payroll is informed. The steps, roles, and transitions are decided by the product. What the client configures is the content of the rules (how many days, which type of leave, which calendar), not the structure of the process.
This distinction between what and how is the heart of the matter. Software without a point of view lets the user define the how: the workflow structure, the screen sequence, the validation logic. Opinionated software fixes the how and leaves open only the what: business data, thresholds, content specific to each organization.
What it costs to decide
Taking a stand in software is harder than not taking one, contrary to what one might think. Not taking a position means building a framework, a set of generic capabilities that the client will assemble. It is engineering work, sometimes sophisticated, but it does not require understanding the business in depth. You build a space of possibilities.
Taking a position is something else. It requires knowing how the work should unfold, which means having observed enough clients, having understood the regulatory constraints, having identified what distinguishes edge cases from structural ones. The workflow encoded in the software is a bet on the right way of doing things, and that bet must be correct for the majority of users. If it is wrong, you do not have flexible software that adapts, you have rigid software that blocks.
This is why opinionated software ages differently. When it is right, it is perceived as simple, fluid, obvious. When it is wrong, it is perceived as constraining, closed, ill-suited. There is no comfortable middle ground. The software's opinion is either an accelerator or a wall, rarely a minor inconvenience.
The real trade-off
The choice between software with or without a point of view is not an aesthetic or philosophical choice. It is a trade-off on the allocation of complexity. The complexity of the business domain does not disappear, it shifts. Software without an opinion pushes it toward the end user in the form of configuration and decisions to make. Opinionated software absorbs it into the design, in the form of user research, design choices, and opinion debt to maintain over time.
In B2B, where software is used by people who did not choose to use it and who have better things to do than configure it, the second option is almost always the right one. The designer's job is not to offer possibilities, it is to eliminate decisions. Every decision the software makes on behalf of the user is a decision the user does not have to make, and therefore one less moment of friction in their day.
The problem is that it requires being right. And being right requires understanding the business better than most clients understand it themselves, which is the part of product work that can be neither automated nor shortened.