When we inventory a mid-market marketing stack, the tool count is almost always higher than anyone inside the company expects — commonly forty or more once you count everything on the company card. The number of tools doing load-bearing work is usually closer to a dozen.
The waste is the boring part of this. What is genuinely interesting is that everyone involved already knows, and nothing changes anyway. That stability is the thing worth explaining.
Five mechanisms that build a bloated stack
Nobody decides to own forty tools. Five ordinary processes produce that outcome without a single bad decision.
1. Adding is cheap and removing is expensive — socially, not financially. A director can trial a USD 400 a month tool on a card without a conversation. Removing it means telling someone their tool is going away and absorbing the resulting argument. The asymmetry runs one direction, permanently.
2. Tools outlive the problems they were bought for. A tool bought for a 2022 product launch is still renewing in 2026 because the renewal is automatic and the person who bought it changed roles twice.
3. Every reorganisation adds a layer. New leader, new preferences, new tool. The old one rarely leaves — it has users, and switching them off during a reorganisation looks like a political act.
4. Point solutions arrive faster than platforms consolidate. Your main platform ships the feature eventually. By then you have paid for the specialist tool for two years and built three workflows on it.
5. Nobody owns the total. Individual tools have owners. The stack does not. Finance sees the charges but not the overlap; marketing sees the overlap but not the total.
Notice that none of these is a failure of intelligence or diligence. They are structural. Which means exhortation does not fix them — only a governance mechanism does.
What an unused tool actually costs
The licence is the least of it, and focusing on it is why most consolidation business cases are unconvincing.
Cost 1: the licence
Real, visible, and the easiest to defend against because the number is usually small enough to look immaterial in isolation. Twelve immaterial numbers is a material number, which is exactly the argument nobody makes because nobody sees the twelve together.
Cost 2: integration maintenance
Every tool connected to something else is a thing that breaks when either side changes an API, rotates a credential or updates a schema. Someone spends time on that, and that time is not tracked anywhere. A stack with thirty-four integrations has a standing maintenance obligation whether or not anyone has budgeted for it.
Cost 3: duplicated data and the reconciliation tax
Two tools holding contact records means two versions of a person, drifting apart. Somebody notices, exports both, compares them in a spreadsheet and fixes the difference — every month, forever. This is the cost that shows up as "marketing ops is always busy but nothing ships".
Cost 4: the credibility cost
This is the expensive one and it never appears in a business case.
When seven tools can report on the funnel, every number is negotiable. A result someone dislikes can always be challenged by citing a different source. Over time, this does something worse than waste money: it teaches the organisation that marketing numbers are opinions. Once that belief sets in, correct analysis stops changing decisions, which removes the entire point of measuring anything.
Why nobody cuts
Three reasons, all rational from the position of the person not cutting.
Loss aversion is concentrated and gains are diffuse. The person who loses their tool feels it immediately and personally. The saving is spread across a budget nobody experiences directly. Predictably, the person with the concentrated loss argues harder.
Nobody wants to be responsible for the thing that breaks. Switching off a tool nobody appears to use carries a small risk that something quietly depended on it, and a large certainty of being blamed if so. Doing nothing carries no such risk.
The audit itself has no owner. It is a week of unglamorous work that belongs to no one's objectives, and it makes enemies. It gets scheduled for next quarter, indefinitely.
This is why stack audits usually only happen under budget pressure — the only force strong enough to overcome all three at once. It is also why they go badly when they do happen, because a cost-cutting frame turns every tool into a territory dispute. We described a better framing in a martech consolidation, before and after: run it as a data-trust exercise, and the savings follow without the war.
The twelve that earn their place
Argue with the specifics; the shape holds. For most mid-market marketing organisations, these categories do the actual work.
- CRM — the system of record for people and revenue. Non-negotiable.
- Marketing automation / lifecycle messaging — one tool, not four.
- Website and CMS — including forms, rather than four separate capture mechanisms.
- Product or behavioural analytics — one, with a documented tracking plan.
- Data warehouse — where definitions live once. See the data plumbing nobody budgets for.
- Pipeline / ETL — moving data in without bespoke scripts.
- Business intelligence — one reporting surface everyone uses.
- Ad platforms — counted as one line, managed natively rather than through an abstraction layer you also pay for.
- SEO and content research — one, used weekly.
- Social scheduling and listening — one combined tool unless listening is a genuine core capability.
- Design and asset management — one library, findable.
- Project and workflow — whatever the rest of the company already uses.
Beyond these, a small number of genuinely specialist tools earn their keep: a dedicated tool for a regulated requirement, a niche capability that is core to your differentiation, a research platform for a team that lives in it daily. That is a short list, and it should be short by argument rather than by accident.
The strongest argument against this position
Stated fairly, because a point of view that cannot survive its counter-argument is not worth publishing.
Tool count is a lagging indicator of experimentation, and experimentation is valuable. A team that trials nothing has a tidy stack and no idea what is available. Some of those forty tools are trials that will become the eleven that matter next year. Optimising the count directly punishes the behaviour that finds new capability.
We think that argument is right in principle and usually wrong in practice, for one specific reason: experiments that are never concluded are not experiments. A trial with a decision date and a named owner is healthy. A trial that silently becomes a renewal is just an accumulation with better branding.
So the actual position is narrower than the headline. It is not "fewer tools are better". It is: every tool should be able to name its owner, its job, and its last decision date. Stacks that pass that test are usually smaller, but the smallness is a symptom rather than the goal.
The one-day version
You do not need a project to find out where you stand.
- Pull every recurring software charge from finance for the last twelve months. Not a tools list — the list is always incomplete.
- Get 90-day active user counts from each vendor's admin panel.
- Write a named owner beside each tool. Anything you cannot assign in one pass is already answered.
- Group by category and flag every category with three or more entries.
Most teams find the exercise uncomfortable in a useful way. The number is rarely the shock. The number of tools with no owner usually is.
If you would rather someone else ran it, that is a fixed-scope piece of work our business automation team does regularly — and the honest outcome is sometimes that your stack is already right-sized.
Leave a Comment