The Jevons paradox of custom software

In the nineteenth century, William Stanley Jevons observed that improving the efficiency with which coal was used did not guarantee a reduction in consumption. By making more uses affordable, efficiency could expand total demand.

Applying that idea to software does not prove an economic law. It is a useful hypothesis for thinking about what happens when AI lowers the marginal cost of designing, building and maintaining specific solutions.

The threshold for what deserves software

Until now, many needs remained in a spreadsheet, an email chain or a manual task. Not because they were irrelevant, but because the cost of analysing them, developing an application, integrating it and maintaining it exceeded the expected benefit.

If that cost falls, the catalogue of problems that deserve a digital solution grows. A tool for finding an exact phrase in hours of audio, an interface for a very specific internal operation or an automation used by three people can begin to make sense.

They will not necessarily replace a large corporate system. They will occupy the space that never justified one.

From large projects to small capabilities

The traditional custom-software model tends to concentrate requirements into large projects to amortise initial costs. That creates waiting, dependencies and solutions that try to satisfy many problems at once.

When building a small piece becomes viable, we can compose capabilities: solve one need, observe its value, connect it with others and decide whether it deserves to evolve. The portfolio looks less like a succession of major implementations and more like an ecosystem of intentionally maintained tools.

More software also means more responsibility

The paradox has an uncomfortable side. If we multiply applications without architecture, owners or retirement criteria, we also multiply attack surface, duplicated data, dependencies and cognitive cost.

Something that is cheap to create is not free to own. Every solution needs an answer for authentication, permissions, operations, support, evolution and shutdown. The new economics of software demands portfolio discipline, not a permanent prototype party.

The purchasing question changes

The comparison is no longer limited to standard software versus a large custom development. A third option appears: composing a small solution with platforms, APIs, agents and specific code.

This can be especially relevant for an SME. Many of its differentiating processes are too particular for a standard tool and too small for a traditional project. As the threshold falls, that space opens up.

A hypothesis we should measure

We do not know that every saving will turn into greater demand. There may be limits of attention, trust, integration or regulation. The paradox should therefore be presented as a lens, not an inevitable prediction.

The signal to observe is simple: how many problems previously rejected because of cost return to the conversation, and how much of the total value comes from solutions we would never have built before.

Sources and references

• William Stanley Jevons’s The Coal Question.
• Primary source: Victor’s observations about prototypes and small tools made viable by AI.