Why the Pursuit of Speed Is Creating Tomorrow’s Software Problems

The pressure to deliver ERP and business-critical software faster is often creating hidden costs that organisations will eventually have to address, argues Carl Andrews, CEO, Original Software.

Every CIO has sat through a go-live celebration. The cake, the congratulations, the sense of relief that something finally shipped. What gets talked about less is what happens in the months that follow, when the pressure to deliver on time has quietly passed its costs onto the teams left maintaining what got shipped.

This is not a niche problem. The drive for faster software delivery is accelerating, not slowing down. Sprint cycles are getting shorter, release frequencies are increasing, and the expectation that technology should respond to business needs almost in real time is now standard. Moving faster is usually the right instinct. The question is what gets quietly sacrificed to make it happen.

Where the debt starts

Technical debt rarely arrives with a warning. It builds through decisions that, individually, seem entirely defensible. Documentation gets pushed down the priority list because the team needs to hit a deadline. A workaround is added to an ERP configuration because the proper fix would delay the project. Testing is reduced because timelines are already slipping

A customisation is left in place because replacing it feels too disruptive.

Nobody sets out to accumulate debt. Its what remains after a series of reasonable- sounding decisions made under pressure. What started as a few shortcuts becomes a system that is harder to change, breaks more often, and costs more to maintain than anyone budgeted for.

ERP environments are especially vulnerable. By their nature, they sit at the centre of the organisation, connecting finance, HR, supply chain, procurement and other critical business functions. Over time, years of shortcuts, workarounds and poorly documented changes create complexity that nobody intended, but everyone inherits. The result is predictable, even if the timing isn’t an issue that should have been caught in testing surface, instead in live business processes, usually at the worst possible moment.

Why organisations underestimate the problem

Part of the challenge is that technical debt rarely appears as an obvious cost. Unlike a failed project or a missed deadline, debt accumulates gradually. It shows up as upgrades that take longer than expected. Changes that require more effort than they should. Teams spending weeks investigating issues that once would have been straightforward to resolve.

Because these costs emerge slowly, they are often treated as isolated incidents rather than symptoms of a broader problem. Organisations tend to focus on the visible benefits of delivering quickly while overlooking the long-term consequences of making systems harder to maintain and evolve.

The result is that technical debt often receives attention only when it starts affecting business performance.

The impact on innovation, productivity and resilience

The most significant cost of technical debt is not usually technical. It is strategic. As ERP environments become more complex, IT teams spend more of their time maintaining existing systems and less time delivering new capabilities. Resources that could be supporting transformation projects, process improvements or AI initiatives are instead consumed by troubleshooting, rework and system maintenance.

Innovation slows because every change carries greater risk. Productivity suffers because routine tasks take longer to complete. Resilience declines because systems become harder to test, support and recover when something goes wrong. This creates a frustrating cycle. Organisations push for speed to stay competitive, but the debt created by that speed eventually makes future change slower, more expensive and more difficult to deliver.

Getting the balance right

The answer is not to slow down. Few organisations can afford that. The goal is to build delivery processes that support speed without compromising long-term quality. That starts by recognising that activities such as testing, documentation and governance are not obstacles to delivery. They are what make sustainable delivery possible. For ERP systems in particular, robust regression testing is essential.

It gives organisations confidence that changes, updates and upgrades can be introduced without creating unexpected disruption elsewhere in the business. Combined with greater automation and earlier testing throughout the delivery lifecycle, it helps identify issues before they become costly problems.

Most importantly, organisations need to view technical debt as a business issue rather than a technical one. Decisions made to accelerate delivery today will influence the cost, flexibility and resilience of systems for years to come.

Go-live is not the finish line. It is simply the point where the long-term consequences of those decisions begin to emerge. The organisations that succeed over time will not be those that move fastest in the short term, but those that can continue changing and innovating without being held back by the systems they depend on.