The market wanted more. The system did not.
The product was doing well. Better than well: the market had taken to it and was asking for more. New integrations, new payment providers, new features that meant growth. The timing was perfect. The infrastructure was not.
The payment API I worked on ran on PHP 5.6. Not because nobody knew better. Because for years the feature pressure was higher than the time an upgrade would have taken. Every quarter there were more important things. Every quarter the upgrade was pushed back.
Until the SDKs of the new payment providers required PHP 7.2.
What followed were weeks in which not a single new function could be shipped. No new payment provider. No new feature. Only the upgrade that had been overdue for a long time, and that now had to be done under maximum pressure because there was no other choice left.
At that point technical debt was no longer a developer problem. It was a business problem.
What technical debt really is
Technical debt is deferred decisions that get paid back with interest. Every shortcut a team takes today makes a change tomorrow more expensive. That is not a metaphor. It is mechanics.
In a system that spent years under feature pressure without time for cleanup, those decisions accumulate. Not dramatically. Not visibly. Quietly, until the moment comes when a change that should be trivial takes weeks because nobody understands any more how the pieces fit together.
That is exactly what happened in my project. Not because bad developers were at work. Because good developers under pressure always do the right thing for today, and defer the right thing for tomorrow until tomorrow is no longer an option.
Why nobody listens
I raised it early in that project. Not once, but again and again. The PHP upgrade was overdue. The debt was growing. The moment would come when there was no other way.
The answer was always the same. We know. But right now we have this feature. And after that, that one. And then the next deadline. We will get to it at some point.
That is not bad faith. It is a rational response to short-term pressure. Technical debt sits in the future. The next feature is two weeks away. And in every meeting where priorities are fought over, abstract future risks lose against concrete current requirements.
The problem is that technical debt does not wait to be scheduled. It grows quietly, and it becomes visible exactly when there is no room for it.
How I explain it to CTOs
The mistake many developers make is to communicate technical debt as a technical problem. Refactoring, code quality, architecture: those are terms that create no urgency at C-level.
What creates urgency is business impact.
The question I ask is not: when can we do the upgrade? The question is: what does this upgrade cost us if we do it now, and what does it cost us if we do it in a year under pressure because we have no other choice left?
In my case the answer was unambiguous. The upgrade under pressure cost weeks without feature delivery at a moment when the market was waiting for us. Had we planned it six months earlier it would have cost one sprint, with no external deadline and no brake on growth.
The second lever is visibility. Technical debt has to be measurable to be taken seriously. How long does an average feature take today compared to two years ago? How many bugs come out of code nobody understands any more? How much developer time goes into fixes instead of features? Those numbers tell a story that nobody hears without numbers.
The third lever is timing. Making technical debt into a problem nobody cares about does not work. Positioning it as a strategic investment does. The difference between "we need to refactor" and "we need to invest now so that we can ship faster in six months" is the same fact, but one lands at C-level and one does not.
What actually helps
After the experience with the payment API I changed the way I talk about technical debt. No longer about code, but about the ability to grow.
The most concrete question I ask is: how long did an average feature take two years ago, and how long does it take today? If the answer is "considerably longer" without the team having grown or the features having become more complex, the reason is almost always accumulated technical debt. That number is not a technical metric. It is a business indicator.
The same goes for the share of developer time that disappears into bugfixes and unplanned work instead of flowing into features. If a team spends 40 percent of its time stabilizing existing code, that means 40 percent of the development budget is not being invested in growth. That is a number that lands at C-level.
The third lever is timing. Positioning technical debt as a strategic investment works better than communicating it as a problem. The difference between "we need to refactor" and "we are investing one sprint now so that we can ship twice as fast in six months" is the same fact, but one lands at C-level and one does not.
The moment of clarity
In that project with the payment API, the moment of clarity did not come from a convincing presentation or a well-worded email. It came because there was no other choice left.
That is the most expensive way to understand technical debt. It costs time, growth and in some cases market share that went to competitors in the meantime.
The alternative is uncomfortable but cheaper: make technical debt visible before it escalates, translate it into business language instead of technical terms, and communicate it consistently as a strategic risk, not as a developer preference.
I warned early in that project. I was heard but not prioritized. That is a pattern I have found in almost every grown system since.
Technical debt does not wait. It grows. And it becomes visible exactly when nobody has time for it.
