Technical debt does not only arise from large legacy systems, but also from all those "temporary" solutions that we create every day to make processes work. In this article, some reflections on how invisible technical debt is born and what is needed to govern it before it becomes the legacy of the future.
When we at WEGG talk with IT representatives of companies, it often happens that we hear the same story.
Over time, IT systems have become increasingly complex and layered, to the point where modifying, integrating, or simply evolving them requires a significant effort. Applications developed years ago continue to support critical services, with all the implications in terms of security. Infrastructures that have grown through accumulation and fragile integrations must be constantly maintained to ensure the proper exchange of data.
Think, for example, of billing systems based on custom applications, heavily personalized ERPs, or point-to-point integrations that work only because "nobody touches them". In many cases, the apparently most prudent choice becomes precisely this: not to intervene at all.
This situation often brings to mind the Centennial Light, the famous light bulb installed in 1901 at the Livermore-Pleasanton Fire Department in Livermore, California, which has been almost continuously lit for over a century. No one dares to turn it off for fear that it might never turn back on.
A similar attitude can also be found in companies, where certain systems are left untouched not because they work particularly well, but because no one truly understands how they function in depth. As a result, they continue to be kept alive, often relying on a few key individuals or long-standing vendors, with the sole objective of “keeping them standing".
In these conversations, another fundamental aspect always emerges as well: maintenance does not create value.
It is a necessary expense to ensure operational continuity, but it does not generate competitive advantage. The more technical debt grows, the more the IT budget is absorbed by activities such as patches, updates, managing incompatibilities, and recurring incidents, reducing the room for truly transformative initiatives.
It is not just a perception. In many industries, a very significant portion of the IT budget is absorbed by maintaining existing systems, leaving little room for innovation.
This is the most insidious aspect of technical debt: the progressive loss of flexibility and speed, which over time reduces the organization’s ability to remain competitive. It is no coincidence that the effective adoption of artificial intelligence also largely depends on data quality, the reliability of integrations, and the governability of the IT ecosystem.
When we talk about technical debt, however, we tend to think almost exclusively of large core systems: ERP, mainframes, mission-critical applications. It is the kind of technical debt we are familiar with, the one that appears in modernization plans and multi-year budgets, often associated with major transformation programs. And it is true: this is technical debt.
But it is not the only one. There is also a less visible technical debt, which is born today, day after day, precisely in the points where processes are not governed. This is the legacy of the future—the one we are building without even realizing it.
To fill a jar, we start by adding stones: they represent the major transformation projects, such as cloud migrations, application modernization programs, or upgrades of core systems like SAP. But even when the stones seem to occupy all the available space, the jar is never truly full.
In the gaps, sand seeps in. This is the technical debt that arises from everything that is not governed: a shared Excel file used to manage approvals, an Access database created to track requests, a script developed “on the fly” to automate an operational step. These are solutions that seem harmless, but over time become indispensable.
This phenomenon can be defined as technological personalism: situations in which individual people or teams fill process gaps with provisional solutions that end up becoming structural.
This is how even a simple Excel sheet can turn into technical debt. Not because of the tool itself, but because of the role it takes on when it enters business processes. Excel ceases to be an individual support tool and becomes a small, undeclared application: it contains business rules, calculation logic, and implicit controls often understandable only to the person who created it. When that person changes role or leaves the company, the knowledge embedded in the file becomes difficult, if not impossible, to recover.
Added to this are operational dependencies and security risks: processes that work only with a specific version of the file, macros compatible only with certain releases, and the lack of access controls or change tracking.
The problem is not Excel itself, but the fact that it is used as a structural component of a business process without the safeguards we normally associate with a governed IT system.
It is in this context that shadow IT arises, as a natural response of the business to the need to move faster than traditional IT can often manage. This invisible technical debt also carries with it a maintenance debt: when it is known, it drains resources to manage versions and compatibility; when it is unknown, it tends to surface at the least opportune moment, amplifying the impact of incidents.
If invisible technical debt arises because people independently fill the gaps in processes, the answer cannot be a simple ban. Blocking tools, tightening controls, or further slowing down IT does not eliminate the problem: it merely shifts it elsewhere.
What is needed instead is a change of perspective. IT must be enabled to quickly digitize those operational steps that currently remain unaddressed, before they are handled informally and without governance. Every organization coexists with inevitable process gaps: missing integrations, manual workflows, activities that exist only in people’s knowledge. It is precisely in these spaces that invisible technical debt is born.
The point, then, is not to suppress the business’s need for speed, but to intercept and govern it. This means creating lightweight, digital, and integrated solutions that can evolve over time without becoming new legacy. Only in this way is it possible to reconcile operational speed with control, preventing today’s temporary solutions from becoming tomorrow’s structural constraints.
When a new digital need arises, there are essentially two possible paths: BUY or MAKE.
If a solution exists on the market that adequately meets the need, BUY is almost always the most sustainable choice. It reduces time-to-value, limits risk, and shifts the focus from implementation to process management. When feasible, this path allows organizations to avoid creating new technical debt from the outset.
The problem arises when a ready-made solution does not exist or when the business context is too specific. In these cases, MAKE is often used, typically through custom development. This is where the well-known complexities of traditional development come into play: high costs, long timelines, maintenance difficulties, and limited flexibility over time. Many solutions created to address a specific need thus end up, within a few years, becoming new legacy.
At WEGG, having worked for years on process digitalization, we observe how low-code platforms can represent a more sustainable alternative to traditional development, especially for filling those process gaps that would otherwise be handled by informal and hard-to-govern solutions.
It is important to be clear, however: not all low-code platforms are the same. If adopted without a holistic vision, they can themselves generate fragmentation and new technical debt, replicating the very problems they are meant to solve.
To truly reduce invisible technical debt, a low-code platform cannot be limited to speeding up development. It must be designed to govern a population of applications, not just to quickly create isolated solutions. In practice, this means adopting enterprise-level approaches that allow control, consistency, and long-term sustainability.
In particular, a platform oriented toward governance should guarantee:
Only in this way can low-code become an effective tool for reducing technical debt, rather than accelerating future debt. It is with this approach that, in our digital transformation projects, we adopt an enterprise low-code platform like Mendix, which is also characterized by high integrability within IT environments, coexisting and integrating seamlessly even in already structured ecosystems such as Microsoft and SAP.
The real paradigm shift is this: it’s not about choosing between speed and control, but about creating an ecosystem that enables both.
Invisible technical debt does not arise from wrong choices, but from real needs addressed without a governance vision. Recognizing it early means turning speed into a competitive advantage, rather than a structural constraint.
Insights
OUR OFFICES
OUR OFFICES
PADUA
Via Arnaldo Fusinato 42, 35137
MILAN
Viale Enrico Forlanini 23, 20134
ROME
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
