We have updated our Privacy Policy, click here for more information.
Thank you
David Collins
|
The economics of bespoke software development are shifting fundamentally—and fast. Anyone in procurement reading this is probably saying ‘rubbish, costs do nothing but rise’ and to a certain extent that is ambiguously true as well; but that is because they are only looking at the cost per hour of development.
To fully appreciate the statement you also need to look at the value of what is produced.
Today we are able to deliver outcomes faster and with smaller teams than we were able to several years ago. This is largely to do with improvements in SDLC approach and automation. Agile is more cost effective than waterfall; investments in test and release automation have facilitated faster delivery cycles and the move to elite DevOps (multiple production releases a day) which has hugely increased delivery of functional changes and platform stability.
Now we are starting to see how AI can be used to enhance the SDLC further, allowing additional reductions in team size while driving delivery time down and release frequency up.
As AI exponentially reduces the cost and time taken to write, debug and test code, the input cost will actually become less relevant. Stakeholders will stop asking “How many developers?” and start asking “What did this software actually achieve?”
My guess is that, while procurement does not see this, CTOs instinctively know it but lack objective measurement to prove it. That is an issue for the whole industry because, without the ability to measure outcomes, it makes decisions on applications’ value difficult to quantify.
This also massively impacts the traditional build versus buy dichotomy. As AI reduces the marginal cost of development, teams can experiment more easily and at a vastly reduced cost per iteration. This de-risks implementation and front runs the delivery of value. It is then difficult to compare this approach with buying an off the shelf solution which will typically be a subscription-based contract where you can estimate the TCO by adding in expected infrastructure costs as well as implementation, support and change costs. That might assume the solution lives up to its billing when the reality is often quite different.
Of course, software vendors are exposed to the same factors so we should expect to see the cost of their solutions declining as well. In theory, yes, but where the vendor solution has a monolithic architecture entrenched across multiple clients with custom configurations, their ability to extract the benefits of modern SDLC advances is severely limited. On top of that buyers are exposed to, sometimes steep, cost increases at renewal that can be driven by ownership factors (PE firms) rather than input costs.
Nothing is easy here but organisations that learn to measure software by its value delivered—not input cost—will gain the upper hand.