The economics of building custom software changed. The problem list didn’t.
Most mid-market companies have a list. It isn’t written down anywhere. It’s the accumulated leftovers or remainders of ten years of good software ideas that got priced once and then quietly dropped – the customer portal, the ERP and CRM integration, the internal tool that would finally replace the spreadsheet everyone complains about, the quoting process that still runs through one person’s inbox.
Nobody ever decided those problems weren’t real. They were real, and most of them still are. What happened is that each one got a dollar attached to it, and the number was bigger than the problem. So the problem stayed.
Now, that arithmetic has changed. It’s worth understanding why, because the reason matters considerably more than the headline.
Why the list existed in the first place
Custom software used to carry a fixed overhead that had very little to do with the size of the project.
Every build needed roughly the same scaffolding regardless of scope: requirements gathering, architecture decisions, environment setup, testing, deployment, documentation, and someone to maintain it afterward. On a two-year platform program, that overhead disappeared into a large budget. On a focused eight-week project worth $60,000 a year in recovered operating cost, the overhead was the budget.
The result was a hard floor. Above the floor, projects got built. Below it, they didn’t – regardless of how obviously worthwhile they were. A distributor who could give back four hours a day of account-manager time by letting customers check their own order status would get a quote for a portal, look at the number, and decide to keep answering the phone.
That was not a failure of vision. Given the price, it was the correct decision.
What’s actually changed?
AI compressed the part of software development that was always the most labor-intensive and the least differentiated: producing the code.
It’s worth being precise about the scope of that, because the precision is where the useful part lives. What got dramatically faster is implementation – turning a well-specified requirement into working software. What did not get faster, and arguably got harder, is everything surrounding it: deciding what to build, sequencing it correctly, understanding how it touches the systems already running the business, and being confident it will hold up against real data volumes, real edge cases, and real users.
The practical effect is that the overhead on a project is now weighted differently. Less of it sits in production, more of it sits in judgment. Which means the question in front of a mid-market operator is no longer “can we afford to build this” nearly as often as it is “do we know enough to build this correctly.”
The Projects To Start With
In practice, the shelved items that become viable soonest tend to share a shape. They’re bounded, they have a measurable operating cost attached to the current workaround, and they don’t require replacing anything load-bearing.
- Customer Self-Service
Order status, account history, reorders, documentation. The single most common source of inbound calls in distribution, and among the most mechanical to answer with software. - Integrations Between Owned Systems
The ERP and the CRM. The warehouse system and the accounting system. Five years ago each connector was its own project with its own justification. That calculus has shifted the most of anything on this list. - Internal tooling that replaces a spreadsheet
Usually a spreadsheet that one person maintains, that three departments depend on, and that nobody fully trusts. - Quoting and configuration
Where product complexity has outgrown the process, and the bottleneck is one experienced person’s availability. Better and faster quoting should also deliver a net order increase return.
What these have in common is that the cost of not doing them is already being paid, every month, in labor. It’s simply not on any line item, which is why it never competed well for capital.
The failure mode worth planning around
There’s an obvious counter-argument, and it deserves to be taken seriously: if building software is this much cheaper now, why involve anyone at all?
Because a large number of people have now tried exactly that, and the pattern is consistent enough to be predictable. Someone builds a working prototype in a weekend. It demonstrates the concept convincingly, and it demonstrates it to the people holding the budget. Then it meets production – actual data volumes, edge cases nobody anticipated, an authentication requirement nobody specified, a compliance question nobody asked. Code that looked right and passed a review breaks in a way that’s expensive to diagnose, because nobody can explain why it was written the way it was written. It’s where the senior expertise is required.
The prototype wasn’t the mistake. Treating the prototype as the finish line was. Speed of production and durability of what’s produced turn out to be separate problems, and only one of them got solved.
What’s emerging in response
Across the industry, a way of working has started to take shape in response to that gap. It gets described in different ways, but the shared idea is usually some version of guided AI: senior engineering expertise determines what gets built and in what order, guardrails inside the process govern how it gets built, and a structured framework keeps decisions traceable from the first requirement through to deployment.
The distinction it draws is between AI as an autonomous builder and AI as an accelerator operating inside constraints someone experienced has set. The first is fast and unpredictable. The second is fast and reviewable, which matters more than it sounds – because reviewable is what lets a business inherit and manage software rather than merely receive it.
That distinction is the whole reason the shelved list is worth revisiting rather than simply being handed to the fastest available tool.
How To Reprice Your List
If you have a list, four questions will sort it quickly:
- What does the current workaround cost annually?
Count labor honestly, including the senior people absorbing exceptions. This number is almost always larger than expected, and it’s the actual budget. - What breaks if it’s wrong?
A tool that misroutes an internal task is a different risk profile from one that misprices a customer order. The answer determines how much governance the project needs, and therefore what it really costs. - What does it have to talk to?
Integration surface area is the most reliable predictor of difficulty. Two systems is a project. Six is a program. - Who owns the decisions?
Not the budget – the decisions. Every one of these projects generates dozens of small architectural choices, and the outcome depends far more on who makes them than on how quickly they get implemented.
Anything that scores well on the first two and modestly on the third is probably a project you deferred for reasons that no longer apply.
The constraint moved
The list didn’t get shorter over the last decade. If anything it got longer, because customer expectations kept moving while the technology under most mid-market operations didn’t.
What changed is that cost stopped being the constraint.
It’s worth pulling the list back out.
