The Excel Problem Is Back — This Time It Builds Software
Cheap creation is an opportunity. Unmanaged dependency is the risk. The difficulty is that nothing announces the moment a convenience became critical infrastructure.
Somewhere in every established company there is a spreadsheet that should not be load-bearing and is.
It was not a mistake. Someone needed a calculation and produced one in an afternoon, which was the correct decision at the time. What happened afterwards was not a decision at all.
Excel democratised computing, and that was good
It is worth being clear about this before anything else, because the argument is routinely mistaken for its opposite. Spreadsheets put computation in the hands of people who understood the business and did not write code. The value created by that is enormous and largely uncounted. Any account of what went wrong that starts by blaming the tool has misread the situation.
What spreadsheets also did was remove the friction that used to force a second conversation. When building something took a department, a budget and six weeks, somebody asked what it was for, who would own it and what happened if it was wrong. Not because those people were wiser, but because the cost of building created a natural checkpoint.
How convenience becomes infrastructure
The sequence is consistent enough to be worth writing down.
A calculation
One person needs an answer that no system provides. The spreadsheet takes an afternoon and is unambiguously the right call.
A workflow
Two colleagues start using it. It acquires tabs, lookups and a colour convention that everybody understands and nobody wrote down.
A process
A monthly deadline now depends on it. It is emailed rather than shared, so several versions exist, and one of them is authoritative for reasons of habit.
A dependency
Another team consumes its output. Someone builds a report on top of it. It now has downstream consumers who have never seen the formulas.
Mission critical
The author has left. The process cannot pause. Nobody has read the formulas in three years, and nobody wants to be the person who changes them.
No step in that chain is unreasonable, and no step announces itself. That is the whole problem. The classification usually happens retrospectively, during an incident, in a room where somebody asks who owns this and the answer takes a while.
Excel was never the problem. The problem was a cheap tool becoming responsible for an expensive process.
AI democratises building, and that is also good
Everything above is now available at a different speed. A business analyst can produce an application in an afternoon, an approval workflow before lunch, an agent that reads incoming documents and writes to a system of record before the meeting it was discussed in has finished.
This is genuinely valuable. The alternative — a queue in front of a technology function that will get to it next quarter — was never a superior state of affairs. Companies that suppress this will lose to companies that use it.
But the lifecycle from idea to business dependency has compressed from years to weeks, while the organisational machinery that classifies dependencies has not moved at all. The gap between what can be built and what is governed is not a new problem. It is an old problem arriving faster than the process designed to catch it.
The critical process test
The useful question is not whether something was built properly. It is what depends on it. One question separates the two.
What happens if this tool is wrong for one day?
The answer places it on a scale that is conceptual rather than scientific, and that is sufficient. Convenience: somebody is annoyed. Productivity: work slows. Operational dependency: a process stops or produces a wrong result that has to be found and corrected. Mission critical: production, money, compliance, safety or customer trust are affected before anyone notices.
Wherever a tool lands above the first level, six further questions follow, and they are all cheap to ask.
- Who owns it — as a named person, not a department?
- Who understands it well enough to change it safely?
- How is it tested, and against what?
- How would anyone know it had started producing wrong answers?
- What is the fallback, and has anyone ever used it?
- What data does it depend on, and who is responsible for that data being right?
None of that is a governance programme. It is an inventory, and it is far cheaper to write while the list is still short.
What companies should actually do
Not ban AI-created software. That answer fails on its own terms: it forfeits the productivity, and the building happens anyway, further out of sight. The workable answer is to classify by criticality and let the classification set the standard.
Low criticality
Prototype freely. No approval, no documentation requirement, no ceremony. Most of what gets built belongs here, and treating it otherwise is how an organisation teaches people to build in secret.
Medium criticality
A named owner, enough documentation for a successor, and tests that would catch the obvious failure. The cost is hours, not weeks.
High criticality
Architecture review, a security boundary someone has actually thought about, monitoring that would notice a wrong answer, and a fallback that has been exercised at least once.
Mission critical
Professional lifecycle management and explicit accountability. If the process would appear in a business continuity plan, the system carrying it belongs under the same discipline as any other critical asset — whoever built it, and however quickly.
The classification matters more than the standard attached to it. Most organisations already know how to run a critical system. What they no longer know is which of their systems are critical, because the list is growing faster than anyone is updating it.
Why this belongs in a diligence, not only in an IT review
For an owner or an acquirer, this is not a technology hygiene question. A business whose critical processes rest on undocumented tools has a cost that has not been recognised: at some point someone will pay to rebuild them, and the timing of that payment is not under management’s control.
It is also a straightforward thing to examine. Ask which processes would stop, then ask what carries them, then ask who owns those things. The distance between the first answer and the third is the finding — the same question a technology and AI due diligence puts to a target, and the same one a board should be asking about the company it already owns.
Democratised creation is an opportunity. Unmanaged dependency is the risk.
The companion question — why creation cost stopped being a useful guide to anything — is cheap to build, expensive to fail.