Software maintenance that doesn't depend on a person you can't find on the market

Every legacy system has a person. Sometimes it's whoever wrote the original code, sometimes it's whoever inherited the most recent ticket and read through it line by line until it made sense. As long as that person is around, the system "works." The day they leave, and they do, sooner or later, the system keeps running, but no one can touch it safely anymore.

That's the scenario we see most often when a company approaches us for the first time. It's not a request for a new website, it's not an ambitious rewrite. It's: "this system needs to keep working, and the person who took care of it isn't here anymore."

This isn't rare or exaggerated. Gartner estimates that a large share of enterprise IT budgets is consumed simply keeping existing systems alive, with departments losing up to 40% of IT spend to accumulated technical debt, money that doesn't become new product, it becomes survival of what's already live. At the same time, Gartner projects that architectural technical debt, the most expensive kind and the hardest to fix with a one-off refactor, will jump from roughly 30% of all technical debt in 2024 to 80% by 2027. In other words: the problem isn't shrinking over time, it's changing shape and becoming more structural.

That's why the first module Fiscalizei puts into production with a new client isn't code generation, it's diagnosis. We register the repository, the environment, whatever documentation exists (even if it's little or none), and from there the system enters a real maintenance pipeline: tickets with severity, SLA defined before opening, and an audit trail for every change made to production.

That changes the question the company asks. It stops being "who knows how to touch this?" and becomes "what's the ticket protocol?", a question anyone on the team can answer, because the answer is on record, not in someone's head.

There's also a well-known side effect of letting technical debt pile up without a formal process behind it: it doesn't grow linearly. Industry analyses built on Gartner's research show organizations that ignore technical debt spending up to 40% more on maintenance than peers who address it continuously, and roughly 93% of development teams already report living with some level of technical debt day to day, with architectural debt the most frequently cited kind. The market pattern, per Gartner itself, is that a significant share of engineering time, historically estimated by industry analysts at around a quarter of total team capacity, ends up spent just keeping systems standing, even at organizations that consider themselves technologically mature.

The core point isn't that technical debt exists, it always will. The point is that without a formal maintenance process, with severity, SLA and an audit trail, a company's technical debt stays invisible until the day it becomes an incident. And on that day, it almost always runs into the same question that opened this article: besides the person who's already gone, who knows how to touch this safely?

That's why we treat maintenance as the first deliverable, not as a post-sale support line item. A system that enters Fiscalizei's pipeline leaves the "depends on a person" logic behind and enters "depends on a process" logic, one that's auditable, measurable and, most importantly, survives any single person leaving the team, including ours.