Why AI changes the economics of custom enterprise software

Every company runs on a layer of processes that nobody would defend in a meeting. A spreadsheet with twelve tabs and one owner. A shared mailbox that functions as a workflow engine. A weekly export reconciled by hand. These are not failures of management; they are rational responses to a cost curve. Building software for them was never worth it.

That curve has moved. When a focused internal application costs a fraction of what it cost three years ago, a large set of processes crosses from 'tolerate' into 'worth building'.

Where the money actually went

The historical cost of custom software was not mostly typing. It was coordination: specification, translation between business and engineering, project management, rework caused by late feedback, and the overhead of teams large enough to need managing.

AI has not made engineers ten times faster at thinking. It has removed most of the cost of being wrong on the first attempt.

That distinction matters for budgeting. The saving is not a discount on the same delivery model — it comes from a different model, with fewer people, fewer handovers and shorter feedback loops. Applying AI tooling to an unchanged twelve-person project structure produces a faster version of the same overhead.

What the new threshold looks like

A practical test: if a process consumes more than a few person-days a month, has a clear owner, and is currently held together by a spreadsheet or a mailbox, it is now a candidate for its own application. That test would have been absurd in 2018.

• The cost of the wrong decision is smaller, because the build is smaller.
• The value is easier to measure, because the process already has a visible cost in hours.
• The alternative — another module, another licence, another configuration project — often carries more long-term cost than the build.

The cost that did not disappear

Software still has to be owned. Something that runs the month-end process needs authentication, permissions, monitoring, a backup strategy and someone accountable when it breaks. The build got cheaper; the responsibility did not.

The organisations that benefit most are the ones that treat this as a portfolio question: which processes deserve real software, which should stay in a standard system, and which should be retired rather than automated.