When something in a business is not working smoothly, there is a reflex that feels like progress: add a tool. A process is messy, so a new app is bought to manage it. Reporting is painful, so a dashboarding tool is added. Two teams cannot coordinate, so a new platform is introduced to connect them. Each decision is reasonable, each tool genuinely solves the problem in front of it, and each one is adopted with a sense of having fixed something. What is almost never counted, in the moment of adding it, is that a tool is not a one-off purchase. It is a permanent thing to run, and the cost of running it is paid every day for as long as it exists.
This is why so many organisations end up quietly drowning in software. Not through one bad decision, but through a long series of individually sensible ones, each of which added a system and none of which removed one. The result is tool sprawl: more platforms than anyone can see across, data scattered among them, and people spending a surprising share of their time moving information between tools and working out which one to believe. The tools were meant to reduce friction. Past a certain point, they become the friction.
A tool is a liability, not just a purchase
The trap is thinking of a new tool as something you buy, when it is really something you take on. The licence fee is the smallest and most visible part of the cost. The real weight is everything that follows. The tool needs an owner, someone responsible for configuring it, keeping it updated, and deciding how it is used. It needs data, kept accurate and current, or it quietly becomes misleading. It needs to connect to the other systems it depends on, and every one of those connections is itself something to build and maintain. It needs people to learn it, and it needs securing and licensing. And it becomes one more place where a version of the truth now lives, which means one more thing to reconcile against everything else. None of that appears on the invoice, and all of it is permanent.
The costs are invisible, which is why they accumulate
If the full running cost of a tool were presented at the moment of purchase, far fewer tools would be bought. But the cost is not presented that way. It is spread thinly across time and across people: a little of an administrator's attention, a little of everyone's time spent switching contexts, a little more data to keep in sync, a slightly longer onboarding for every new hire. Each increment is too small to object to, so no one does, which is exactly the same mechanism that lets exceptions and workarounds pile up unnoticed. The tool that was added to save time keeps a running tab that no one adds up, and the bill only becomes visible in aggregate, as a vague and growing sense that everything takes more coordination than it should.
Sprawl has a shape, and it is expensive
When tools accumulate, the damage is not just the sum of their individual costs; it is what they do to each other. Data fragments, so the same customer or order exists in five systems with five slightly different versions, and answering a simple question means deciding which to trust. Integrations multiply, because every new tool wants to talk to the others, and a web of connections is far harder to maintain than any single tool. People pay a switching tax all day, moving between systems and holding in their heads which tool is used for what. And knowledge thins out, because no one understands the whole estate; each tool is known by a couple of people, and the map of how they fit together exists nowhere. A business with the right small number of well-run systems is calm. A business with too many is busy in a way that produces friction rather than output.
Add with discipline, and subtract on purpose
The answer is not to refuse all new tools; some are genuinely worth their permanent cost, and starving a business of the software it needs is its own mistake. The answer is to make the decision honestly. Before adding a tool, ask whether a system you already run can do the job well enough, because extending something you already maintain is almost always cheaper to live with than standing up something new. Ask who will own it, how it will get and keep good data, and what it will have to integrate with. And weigh what it will cost to run every year, not just what it costs to buy. Most usefully, treat your set of tools as something to be kept deliberately small: when you add, look for something to retire or consolidate, so the estate stops growing by default. Tools should have to earn their place not once, at purchase, but continually, by being worth the standing cost of running them.
A worked example
A mid-sized company came to us convinced they needed yet another platform to pull their operation together, because nothing seemed to join up. When we mapped what they were already running, the real problem was obvious: they had accumulated more than a dozen tools over several years, many overlapping, several barely used, and almost none of them talking to each other cleanly. The same data lived in a CRM, two spreadsheets, a project tool, and a finance system, and staff spent hours a week keeping them roughly aligned by hand. Adding another platform on top would have made it worse. Instead we did the opposite. We worked out which few systems should be the real homes for each kind of information, consolidated onto them, retired the tools that were duplicating or barely earning their place, and built a small number of solid integrations between the ones that remained. They ended up running fewer tools, not more, and the coordination problem that had prompted the search for a new platform largely dissolved, because it had been created by the sprawl in the first place.
Fewer, better-run systems
The instinct to solve a problem by adding a tool is natural, because adding is easy and visible and feels like action. But every tool added is a commitment to run it forever, and a business that only ever adds will end up spending more effort operating its software than getting value from it. The organisations that stay effective are not the ones with the most tools; they are the ones that treat every system as a standing cost, keep the number deliberately small, and make each one earn its place. Before you add the next tool, the most valuable question is not whether it would help, because almost anything would help a little. It is whether it is worth running for years, and what you will remove to make room for it.
Getting to a deliberately small set of well-run systems that actually fit together, rather than an ever-growing pile of tools nobody can see across, is exactly what our enterprise architecture and roadmapping work is built around: deciding what each system is for, consolidating what has sprawled, and integrating what remains. Book a discovery call and we will help you run fewer, better tools.
Frequently asked questions
What is tool sprawl?
Tool sprawl is the slow accumulation of software tools across a business, each adopted for a good local reason and none ever removed, until the organisation is running far more systems than anyone can see across or manage well. It happens because adding a tool is easy and visibly solves a problem, while the ongoing cost of owning it is spread out and invisible. Over time the data ends up fragmented across many systems, the same information is entered in several places, and staff spend their days switching between tools and reconciling them. Like exceptions and workarounds, each individual tool is justifiable; the damage is in the accumulation nobody is tracking.
Why is adding a new tool more expensive than it looks?
Because the purchase price is the smallest part of the cost. Every tool you adopt has to be owned by someone, kept configured and updated, fed accurate data, connected to the other systems it needs to talk to, learned by the people who use it, and secured and licensed. It also becomes one more place where a version of the truth lives, which means more reconciliation and more chances for numbers to disagree. These costs are paid quietly, every day, for as long as the tool exists, and they rarely show up in the decision to buy it, which is why tools are adopted far more readily than the true cost would justify.
How do you decide whether to add a new tool?
Start by treating the decision as taking on a permanent liability, not making a one-off purchase. Ask whether a system you already run can do the job well enough, because one more capability in an existing tool is almost always cheaper to live with than a new tool. Ask who will own it, how it will get and keep accurate data, and what it will need to integrate with. And ask what it will cost to run every year, not just to buy. A useful discipline is to require that something is retired or consolidated when something new is added, so the total number of systems stays under control rather than only ever growing.
What are the signs a business has too many tools?
The clearest signs are data that lives in many places and never quite agrees, people copying information from one system into another by hand, and nobody being able to give a straight answer to a simple question because the answer depends on which tool you ask. Other signs include a long list of software subscriptions that no single person fully understands, tools that only one employee knows how to use, and integrations that break and take real effort to fix. If onboarding a new hire means teaching them a dozen systems and the informal rules for which one to trust, the tools have stopped serving the work and started being the work.