While technical debt is a common topic in software and system development circles, its wider impact on business performance is often underestimated. A recent Forbes article - Investing In Business: Advancing Payment Technology While Keeping Tech Debt Under Control, offers a solid foundation for understanding how to manage technical debt—particularly within payment systems. Technical debt is like a loan you take out in code, requiring interest payments of extra effort later because of prioritizing speed over quality in software development.
That said, there are deeper nuances and overlooked areas within the article that warrant further discussion.
To start, understand that not all technical debt is bad. Like financial Debt, it can be leveraged for growth. Technical debt is not a monolithic problem, like how the article has treated it.
For example, if you have a “million dollars idea” but you are unsure if there is a market demand. You may use a quick-and-dirty MVP to validate the market response and refactor to enhance it later. The key here is intentionality, understanding when to take on debt and when to pay it down.
As the Head of Software at Aonic, I make sure all our developers have the technical expertise and support they need to complete their Sprint tasks effectively—within the estimated time and resource constraints, without being overloaded. This balanced approach keeps the team motivated, encourages consistent delivery, and fosters long-term growth by helping them build skills and confidence with each success.
It is important to us at Aonic to prioritise long term health, not just short-term wins.
The Forbes article focuses on systems but overlooks at how company culture can contribute to technical debt. Short-term thinking only leads to pressured employees to deliver features at all costs and employees’ lack of engineering empowerment may create systemic debt accumulation.
We recently revamped our Aonic Agriculture App to support our Aonic Flex program, a credit leasing program to purchase agrochemical products on credit. Many of the features we built, during the first three months of the first stage, were designed to be future-proof. While product inventory isn’t visible in the initial phase, we’ve already implemented the necessary stock tracking functionality. This ensures our branches across Malaysia will be prepared when purchases begin and avoids the need for major enhancements down the line since stock availability will rely on that functionality.
A lot of businesses prioritize paying down debt later, but in reality, “later” rarely comes. The obvious reason is because technical debt will not appear in the financial statements until it becomes a “crisis”. Treat technical debt like financial liability, make sure to track it and measure its interest like losing in productivity due to challenges such as maintaining it. Plan the schedule repayments of the debt.
At Aonic, our developers utilize AI-powered coding tools to generate initial code drafts when building new features. While these tools help speed up development by minimizing the need to write code from scratch, our team along with our documentation standards require a deep understanding of the generated code. This ensures quality and maintainability, all while allowing us to complete our first phase of the Aonic Agriculture App in a short timeframe.
We require our developers to fully understand and document the generated code. The tools are an asset—but only in the hands of people who know how to use them responsibly. Without this discipline, AI-generated code will quietly become a new form of debt. Fast today, unmaintainable tomorrow.
Regardless of how well your system is architected, if information is not preserved, it will end up becoming debt-ridden. Without proper documentation, maintaining it will become expensive because no one knows how it works.
At Aonic, our developers adhere to strict documentation standards, starting from code-level annotations all the way through to comprehensive technical specifications. We also implement pair programming to ensure continuity—so there’s always at least one developer available to provide support in the event that the other is unavailable.
We often measure progress by what’s visible—features shipped, deadlines met, systems launched. But what about the invisible costs? The quiet shortcuts, the knowledge lost, the cultural habits that shape how we build? Technical debt isn’t always a line of bad code—it’s a reflection of priorities, pressure, and trade-offs we silently accept. If we want to build companies that last, maybe the real question isn’t how fast we can go, but what kind of legacy we’re leaving behind in our code, our teams, and our thinking.
So, how do you or your organization handle technical debt?
