Someone in operations built a spreadsheet four years ago to track a handoff between two teams. It worked. A second team started using it. A manager began pulling numbers from it for a monthly report. Someone added a macro. Today a process nobody documented depends on a file nobody owns.
The same pattern produces the internal script, the shared database, and the app someone built over a weekend. The tool is rarely the problem. The problem is that it crossed a line without anyone deciding it should, and the business now carries a dependency it never evaluated and cannot find on any budget line.
The tool is rarely the problem. The problem is that it crossed a line without anyone deciding it should, and the business now carries a dependency it never evaluated and cannot find on any budget line.
The Tool Nobody Decided to Build Became Infrastructure
Purchased software arrives with a paper trail. There is a contract, a renewal date, an assigned administrator, a vendor obligation, and usually a security review, and every one of those artifacts creates a moment where someone asks who depends on this and what happens if it breaks.
Internally built tools skip all of it. No procurement event, no onboarding, no owner assignment, so nothing in the organization's normal governance ever touches them. The tool accumulates responsibility through use rather than through a decision, which makes the moment it becomes infrastructure invisible by design.
Industry inventories of end-user computing applications find that spreadsheets account for 90% or more of what organizations discover when they look, and that 88% of them contain formula or data lineage errors. Those are only the tools that got counted.
How Do You Know an Internal Tool Has Outgrown Its Original Purpose?
An internal tool has outgrown its original purpose once other people's work depends on it and only one person can maintain it. That combination, dependency without redundancy, is what separates a useful shortcut from an operational risk. Five signals tend to appear together:
People outside the original team use it, or ask the original team to run it on their behalf.
Its output feeds a decision, a report, or a customer commitment rather than an internal convenience.
One person can change it safely, and everyone knows exactly who that person is.
Documentation does not exist, or it exists as a conversation rather than a document.
Nobody can answer what would happen tomorrow if it stopped working.
The fifth signal is the most useful diagnostic, because the inability to answer the question is itself the finding. A tool whose failure consequences are unknown has already become something the organization is exposed to rather than something it uses.
Ownership Disappears Long Before the Tool Does
The original builder gets promoted, changes teams, or leaves. The tool keeps running, which is precisely why nobody treats the departure as an event. Reporting on service accounts finds that 67% lack documented ownership, and informal tools follow the same pattern because nothing in offboarding asks who inherits them.
The security industry has largely reduced the ownership question to credential hygiene, but the operational cost is bigger and arrives earlier. With no owner, nobody can approve a change, nobody is accountable when output looks wrong, and nobody has standing to request budget. Ownership defaults to whoever is nearest when it fails, usually the person least equipped to fix it.
Naming an owner is cheap and it is the step that makes every other one possible. That person does not need to have built the tool. They need to know what depends on it, who can change it, and what the plan is when it breaks. Marcel Digital treats that inventory as the first deliverable in application modernization work, because a tool with no owner cannot be scoped, budgeted, or safely retired.
Undocumented Logic Turns One Person Into a Single Point of Failure
An informal tool is undocumented code carrying real business decisions. Thresholds, exceptions, rounding rules, and edge case handling all live inside formulas and scripts, and each represents a choice somebody made and never wrote down. Analysts describing legacy environments call this the state where the system is the documentation.
When the person holding that context leaves, the reasoning goes with them. What remains works until circumstances change, and then nobody can tell whether an unexpected result is a bug or the tool behaving exactly as intended. New team members will not touch it, which is a rational response to a system that gives no signal when it is wrong.
The exposure does not require anyone to quit, since a vacation or a competing priority is enough to stall a process. Rebuilding the logic inside supported custom web applications or a cloud application environment converts institutional memory into something the organization holds.
What Happens When More Departments Depend on an Unsupported Tool?
Each additional department raises both the consequence of failure and the difficulty of replacement, which is why the risk compounds rather than accumulating in a straight line. One team's workaround has one failure path. Five teams create five processes that stop, each having built assumptions on top of behavior nobody specified.
Replacement gets harder on the same curve. More dependents mean more stakeholders to align, more undocumented edge cases to discover, and more political friction, since any change now threatens someone's working process. The tool becomes too embedded to remove and too fragile to trust, and organizations often learn both facts in the same week.
Data trapped in an unsupported tool also cannot feed reporting, be integrated, or support automation, so the constraint quietly shapes what the business believes is possible. Marcel Digital encounters these tools regularly during platform integration and digital transformation work, where one undocumented dependency turns out to be why a larger initiative cannot move.
Getting Budget Means Pricing What the Tool Already Costs
The obvious framing is the losing one. A CFO hearing a request to rebuild working software is being asked to spend money on a problem they cannot see, and they are right that the tool works. The case has to shift from what replacement would cost to what the current arrangement already costs, which means making an invisible expense visible in financial terms. Four measurements do most of the work:
Count the hours the tool consumes each month across manual steps, reruns after failures, reconciliation of bad output, and the builder's time answering questions about it.
Name each dependent process and estimate the cost of one day of that process stopping.
State the concentration risk in personnel terms, specifically how many people can maintain the tool and what the recovery plan is if they are unavailable.
Identify what the business cannot currently do because the tool cannot support it, whether that is reporting, integration, or scale.
Analyses of legacy environments find that maintenance consumes 60% to 80% of IT budgets, that organizations underestimate the true cost of outdated systems by 40% to 60% because the expense is distributed across departments rather than sitting on one line, and that unaddressed technical debt roughly doubles every four years. Informal tools are the least visible version of that pattern, since they carry no invoice at all.
Framed this way, the request stops being a rebuild and becomes a risk transfer with a measurable current cost, which is a conversation a finance team can evaluate.
Marcel Digital Helps Teams Replace Informal Tools Before They Fail
Marcel Digital works with organizations to identify which internal tools have become operational dependencies, document the business logic inside them, and replace them with supported systems without interrupting the processes that rely on them.
The team supports dependency mapping, application modernization, and development across technology platforms for companies whose critical processes run on tools nobody planned to build. For teams already carrying a full roadmap, enterprise development support adds capacity without displacing committed work.
If a spreadsheet, script, or internal tool has quietly become something your business cannot operate without, connect with Marcel Digital to scope a path off it before the decision gets made for you.
Frequently Asked Questions About Internal Software Risk
Usually both, but the operational risk shows up first and gets less attention. Security conversations about shadow IT assume nobody in the company knows the tool exists. Here, everyone does, and the tool gets sanctioned simply through use, which leaves a business process running with no owner, no documentation, and no support path.
It depends on whether the tool reflects something specific to how the business operates or simply fills a gap in what was available when it was built. Generic logic is usually better served by off-the-shelf software, while a process particular to the business tends to hold more value when rebuilt as a supported custom web application. Either way, that decision should wait until the logic has been documented.
Start with dependencies rather than code. Record who uses the tool, what decisions its output feeds, and what breaks downstream if it stops. Then work with the original builder, while they are still available, to capture the thresholds, exceptions, and edge cases that only exist in their head.
Add one checkpoint rather than a policy restricting what people can build. Once a tool is used by anyone outside the team that built it, give it an owner, a short written description, and a note on what depends on it, and make ownership review part of offboarding so departing employees’ tools are not left behind.
