Has AI reopened the custom vs off-the-shelf software debate?

AI changes software build economics

The old argument for off-the-shelf software was mainly financial: building took too long, cost too much, and created maintenance debt. AI-assisted development does not remove those issues, but it changes their magnitude and timing.

Software change requests have new unit costs

The build-versus-buy debate often rested on the cost of the first version. AI shifts attention to the cost of the next version. When AI coding assistants can draft code, generate tests, and propose fixes, the marginal cost of a change request can fall materially. In some organisations, work that previously took a sprint or two becomes a few days, with human review focused on architecture, security, and edge cases. That changes the economics of continuous improvement: fewer backlog items sit untouched because each one feels too expensive.

This does not mean software is now cheap. It means the balance of spend moves. More budget goes into product ownership, data quality, and operational controls. The financial model becomes less about one-off delivery and more about the cost per change, cost per incident, and cost per governed AI decision.

Debugging and maintenance become less of a bottleneck

Maintenance has been the silent killer of many bespoke systems. AI support for debugging, regression testing, and documentation can reduce the drag of an ageing codebase. If defect resolution time drops by, say, 20 to 40 percent, maintenance stops crowding out new capability. The strategic implication is subtle: bespoke software becomes less fragile if the organisation invests in disciplined engineering practices that AI can amplify.

Time-to-value compresses, so mistakes compound faster

Faster build cycles also compress the time available for sense-checking. A poorly specified workflow can be automated quickly and then scaled quickly. AI changes speed, not judgement. The value of governance rises, because the organisation can now industrialise bad decisions as efficiently as good ones.

Off-the-shelf still offers risk transfer

Packaged software is not suddenly obsolete. In many environments, buying still reduces execution risk and improves audit outcomes. AI mainly changes the boundary of what should be standardised versus differentiated.

Packaged systems fit stable, regulated processes

Where processes are mature and externally defined, off-the-shelf remains attractive. Payroll, core accounting, standard HR workflows, and many compliance reporting needs benefit from vendor roadmaps and a large user base. The question is not whether these domains can be built. The question is whether it is rational to own them when the organisation does not compete on them.

Vendor products can reduce certain classes of operational risk

Well-governed vendors can provide patching cadence, security monitoring, and established controls that would be expensive to replicate. This risk transfer can be commercially meaningful. A single avoidable compliance incident can erase the savings from a home-built alternative, particularly in regulated sectors where auditability and segregation of duties matter as much as feature velocity.

AI introduces new forms of lock-in

Off-the-shelf products are increasingly bundling AI features into the suite. That can accelerate adoption, but it can also hide dependencies. If process logic becomes encoded in a vendor-specific workflow engine, and model behaviour is not transparent, switching costs rise. The new lock-in is not only data migration. It is the organisation losing the ability to explain and evidence how outcomes are produced.

So buying can still be correct, but the evaluation criteria need to include AI governance: traceability, override mechanisms, clear liability terms, and evidence that outputs can be audited.

AI in Business: Strategies and Implementation

Artificial intelligence is transforming how modern businesses operate, compete, and grow but its power lies not in blind adoption, but in strategic discernment. This module moves beyond the hype to explore how leaders can make informed...

Learn more

Bespoke software enables AI workflow redesign

AI-native work is less about adding a chatbot and more about rebuilding workflows so decisions, exceptions, and accountability are explicit. Bespoke software is often the most direct way to encode that redesigned operating logic.

Automation moves beyond RPA constraints

RPA scaled best when the world looked like forms and screens. Many knowledge workflows do not. With large language models, prompt templates plus automatic context injection can support tasks such as triaging cases, drafting responses, classifying documents, and preparing decision summaries, even when inputs are messy. These automations often need tight coupling to internal policies, live operational data, and role-based controls. Bespoke systems can provide that coupling without waiting for a vendor roadmap.

Freedom to change becomes a competitive variable

In a volatile environment, competitive advantage often comes from the rate of organisational learning: running controlled experiments, measuring outcomes, and then changing how work is done. If a change to a customer service workflow reduces average handling time from 12 minutes to 9 minutes, that is a 25 percent productivity gain that translates into capacity, service levels, or cost-to-serve improvement. If the software cannot be changed quickly, the organisation cannot compound those gains. AI lowers the cost of change, which increases the value of owning the workflow layer.

Bespoke makes accountability easier to design

Packaged tools can obscure who is responsible for what. AI-native operations need clear decision rights: what the model can do, what it can recommend, and what it must never do without a named human accountable for the outcome. Bespoke applications can hard-code approval points, confidence thresholds, and escalation paths that match the organisation’s risk appetite. That is less glamorous than a new interface, but it is what keeps AI from becoming a reputational liability.

AI operating model determines software value

Whether software is custom or off-the-shelf, the economic outcome is shaped by operating model choices: who owns workflows, who signs off risk, and how performance is measured. Tool selection follows these decisions, not the other way round.

Decision rights need to be explicit

AI-native organisations treat workflows as managed assets. That requires named owners for end-to-end processes, not only system owners. It also requires clear escalation rules: when automation is safe, when a second pair of eyes is required, and when the system must halt and route to exception handling. This is where many pilots stall. The model works in a demo, but no-one wants to own the decision boundary in production.

Central standards with federated delivery

Many organisations land on a split model. Central teams define guardrails, reusable components, privacy and security patterns, and audit requirements. Domain teams own the economics of specific workflows and are accountable for results. This reduces duplication without forcing every use case through a single bottleneck.

Leading and lagging metrics for ROI

Leading indicators show whether AI is embedded in real work: percentage of cases routed through the AI-assisted path, exception rates, decision latency, rework rates, and adherence to workflow controls. Lagging indicators show business outcomes: cost per case, cycle time, margin lift, complaint volume, staff attrition in key roles, and audit findings. The two must be linked. A higher automation rate with rising complaint volume is not progress.

This is one reason LSI tends to frame AI-native transformation as operating model redesign. The systems are the easy part; the measurable behaviour change is the work.

Portfolio choices for production-grade AI

AI reopens the custom versus off-the-shelf debate because it changes the portfolio logic. A single decision for the whole enterprise is rarely credible. The practical approach is to segment by differentiation, risk, and change frequency.

Build the workflow layer that differentiates

Where competitive advantage depends on how decisions are made, bespoke software is increasingly defensible. Examples include underwriting, complex B2B deal shaping, supply chain exception management, and customer retention workflows. These domains evolve with policy, market conditions, and learning. The ability to change weekly, not quarterly, can be worth more than the comfort of a standard suite.

Buy the commodity, own the integration

Packaged systems can remain the system of record. The AI-native opportunity often sits on top: a bespoke workflow and decision layer that orchestrates across systems, captures rationale, and enforces controls. This reduces the temptation to customise vendor products into un-upgradeable shapes, while still enabling differentiated operations.

Kill, contain, or scale pilots with criteria

Pilots should not graduate because they are popular. They should graduate because they shift unit economics without increasing uncontrolled risk. Useful criteria include: a measurable reduction in cost-to-serve of 10 to 20 percent in the target process, stable exception rates, a clear audit trail for AI-influenced decisions, and an owner willing to be accountable for outcomes. If those conditions are not met, the pilot is either contained to a low-risk domain or stopped.

Decision test for the reopened debate

The renewed question is not "build or buy?" It is "what must the organisation be able to change quickly, and what must never change without formal control?" AI makes both sides more important.

The uncomfortable organisational question that follows is simple: when an AI-influenced decision causes harm, is there a named person who can explain the workflow, justify the design choices, and show the evidence trail, or is responsibility dispersed across vendors, tools, and committees?