Your SaaS Stack Is Charging Your Team Interest — The Case for a Tool Debt Audit

Every organisation has a story about technical debt. The legacy system nobody wants to touch. The integration held together with a scheduled script and hope. The database that only one person understands. It is a useful phrase because it makes an invisible cost feel real.

Tool debt deserves the same treatment. It is the accumulated weight of SaaS subscriptions, overlapping apps, half-finished integrations, duplicate workspaces and shadow IT. It rarely appears as a single dramatic failure. Instead, it shows up as a small daily tax: another login, another tab, another place to check, another renewal nobody remembers approving.

My argument is simple. A lot of the UK's productivity puzzle is not a motivation problem or a skills problem. It is a tooling problem hiding in plain sight. Firms are paying interest on tool debt every day, in money and attention, and many have no idea what the principal actually is.

The interest is paid in attention

Software subscriptions are easy to buy and hard to feel. A monthly fee of £12 per user disappears into a company card statement. Multiply it across teams, add a few annual renewals, and the money becomes noticeable. But the bigger cost is often attention.

Every tool adds a place to look. A notification stream. A search box that does not quite find the right thing. A dashboard that someone built two years ago and nobody trusts. A workflow that requires copying data from one app to another because the integration was never finished.

Individually, these are minor annoyances. Collectively, they create a background hum of administrative friction. People spend the first twenty minutes of the day working out where to start rather than doing the work. That is tool debt interest, and it compounds.

How tool debt accumulates without anyone deciding

Tool debt is rarely the result of one bad decision. It arrives through a thousand reasonable ones. A team buys a specialist tool because the central platform is too slow. A manager signs up for a trial and forgets to cancel. A project ends but its workspace stays open. A merger brings two overlapping stacks into the same building. Someone finds a clever app that solves a narrow problem and becomes its unofficial administrator.

Before long, the organisation has a core stack, a departmental stack, a shadow stack and a graveyard stack. The official answer to 'which tool should we use?' is different from the practical answer. New starters learn the workarounds before they learn the policy.

That is not necessarily malice. It is a sign that the central tooling has not kept up with how people actually work. But it is still debt. And like technical debt, it gets more expensive the longer it sits there.

A ledger for your stack

You cannot cull what you cannot see. Start with a simple ledger, not a procurement review. List the tools people actually use, not just the ones finance pays for. Include the free tiers, the trials, the browser extensions and the apps hiding inside larger platforms.

For each tool, capture five things: who owns it, who uses it, what job it does, what it costs and what it connects to. The owner is important. 'Everyone' is not an owner. Neither is 'IT'. You need a named person who can make a decision.

The ledger will be messy. That is fine. The first version is a map, not a masterpiece. The point is to make the invisible visible enough to discuss.

Calculate the interest in money and minutes

Money is the easy part. Add up subscriptions, renewal dates and unused seats. Look for tools with similar overlap. Be honest about the annual plans that were bought for a project that ended in March.

Minutes are harder but more revealing. Ask a handful of teams to estimate how much time they lose each week to switching between tools, hunting for documents, duplicating data or waiting for an integration to catch up. You do not need a perfect study. A rough number from real people is more useful than a polished guess from a spreadsheet.

Then add the hidden costs: the admin time spent managing seats, the security risk of unapproved tools, the training burden of yet another interface, and the morale cost of asking people to care about systems they did not choose.

The cull that does not start a turf war

Tool culls fail when they feel like a central team taking away something a department relies on. They succeed when they start with the work, not the software.

Ask teams what they are trying to achieve, then look for the shortest path. Sometimes the answer is to consolidate. Sometimes it is to keep the specialist tool but connect it properly. Sometimes it is to admit that the central platform is not fit for a particular job and fund the exception openly rather than letting it live as shadow IT.

Give people a trade. If they give up a tool, remove a real friction elsewhere. If they consolidate, make sure the replacement is genuinely better for their daily work. A cull that only saves money but adds hassle will be quietly reversed within a quarter.

What good looks like after the cull

A healthier stack is not necessarily the smallest one. It is the one where people can explain why each tool exists. It has clear owners, sensible renewal dates and integrations that actually work. It has a process for trying new things without letting every trial become permanent. And it has a way to retire tools without pretending the decision was painless.

The UK productivity conversation often reaches for grand explanations: skills gaps, infrastructure, investment. Those matter. But before reaching for the big levers, it is worth looking at the invoice list and the browser bookmarks. The daily interest on tool debt is small enough to ignore and large enough to matter. Paying it down is one of the more practical productivity moves available to UK firms in 2026.