The buy-a-tool reflex is the habit of solving every capability gap with a purchase. It feels like progress. It builds integration debt, overlapping tools, and idle spend. You fix it by defaulting to what you already own or can extend, and requiring a business case that names the missing capability and the revenue it gates.
A team hits a wall. The dashboard cannot do the thing they need this quarter. Someone finds a vendor who can, books a demo, and by Friday there is a new line on the SaaS bill. Nobody checked whether the platform they bought last year already did it.
Why the reflex feels like progress
Buying is a visible action. You can point to it in a status update. A gap gets identified on Monday and closed with a purchase order by Friday, and that looks like momentum. Extending a tool you already own is slower, quieter, and harder to claim credit for. So the reflex wins.
The problem is what the reflex is actually solving for. It solves the discomfort of a gap, not the revenue behind it. Each purchase adds a tool to integrate, a contract to renew, and a data store to sync. The gap closes on paper. The cost compounds off it.
This is the mechanism that builds martech sprawl one reasonable decision at a time. No single buy looks wrong. The sum of them is a stack you use half of.
The evidence
Marketers report being oversold and over-bought, then paying for capability they cannot show value for (AlixPartners via Marketing Week). Read that twice. The problem is not that teams buy bad tools. It is that they buy capability they never activate, then cannot connect it to a result.
The reflex to solve every gap with a purchase is what built the 10,000-tool market and the 49% utilisation rate behind it. Half your stack sits idle. Not because the tools are broken, but because each one was bought to close a gap, not to hit a number, so nobody was ever on the hook to make it pay. That idle half is the subject of a sibling obstacle on martech sprawl.
I have run the other version of this. At dunnhumby we extended the Tesco Clubcard data we already held rather than buying a new platform every time a new question came up, and that discipline is part of how one asset supported a financial-services line that went from zero to 63 million dollars in twelve months. The capability was already owned. The work was turning it on.
Is this you?
Five checks. Yes or no.
- Did you buy a tool in the last year for a job an existing tool could already do?
- Can your team name three features they pay for but have never switched on?
- Does a new gap trigger a vendor search before an audit of what you own?
- Do you evaluate tools by watching demos rather than testing them on your data?
- When you bought your last tool, did anyone name the revenue it would protect or grow?
Three or more yes answers means the reflex is running your procurement, and it is spending money you did not need to spend.
What it costs
The licence is the smallest cost. It is the one you can see, so it gets the attention, and it is rarely the number that hurts.
The real cost is what sits behind it. Every tool you add has to talk to the ones you already run, and that connection work is integration debt you pay down for years. Two tools that overlap mean you pay twice for one capability and split your data across both. A team that could be getting value from the stack it owns is instead onboarding the next tool.
Then there is the opportunity cost. Money spent on a tool you will use at half strength is money not spent on the person who could make an owned tool pay. Idle capability is paid-for capability. The invoice just never says so.
What to do instead
Three moves break the reflex. None of them needs a new purchase.
Default to what you own. Before any vendor search, audit the capability you already pay for. Most gaps are covered by a feature nobody turned on, or a tool one team uses and another has never seen. Extend first. Buy only when you have proven the gap is real and unowned.
Make every purchase earn a business case. Require one that names the specific capability missing and the revenue it gates. If nobody can name the number the tool protects or grows, the purchase is not ready. This single rule kills most reflex buys, because most of them cannot survive the question.
Test, do not watch. Run competitive proofs of concept, not vendor demos. A demo is scripted to make the tool look good. A proof of concept runs two or three tools against your real data and a real task, scored on outcomes you set. You buy what works for you, not what presents well.
This is a procurement discipline, not a project. It applies from your next decision onward, which is why it pays back fast. Get the full buy-a-tool reflex playbook.
Buy last, not first
The point is not to stop buying tools. Good tools earn their place. The point is to make the purchase the last resort, after you have checked what you own, named the revenue at stake, and tested the options on your own data.
The teams pulling ahead are not the ones with the most tools. They are the ones who make every tool prove it before it joins the stack, and who get full value from what they already bought. Ownership of that discipline is a real question in itself, covered in the obstacle on who owns your martech stack.
Go deeper on customer data maximization
Three ways forward. Pick the one that fits where you are.
- Get the playbook. Practical notes on turning the customer data you already own into revenue, straight to your inbox. Join the newsletter at the foot of this page.
- Take the assessment. Score your customer data maximization in four minutes and see your top revenue blockers. Start the assessment →
- Book a meeting. Bring your data problem. Leave with a prioritised fix, not a platform pitch. Book a call →
Post 20 of 25 in the Customer Data Maximization series. Previous: Why does nobody own your martech stack, and what does it cost you?. Next: Why can’t you measure generative AI ROI, and how do you fix it?.
Frequently asked questions
What is the buy-a-tool reflex?
It is the habit of solving every capability gap with a new purchase instead of checking what you already own. It feels like progress because buying is a visible action. It quietly builds integration debt, overlapping tools, and licences nobody uses to full value.
Why is buying more martech usually the wrong first move?
Because most gaps are already covered by a feature you pay for but never turned on. Marketers report being oversold and over-bought, then paying for capability they cannot show value for (AlixPartners via Marketing Week). A new tool adds cost and integration work before it adds revenue.
What should you do before buying a new marketing tool?
Default to using or extending what you already own. Then require a business case that names the specific capability missing and the revenue it gates. If nobody can name the revenue the tool protects or grows, the purchase is not ready, and the gap may already be covered.
What is a competitive proof of concept?
It is a short, hands-on test where two or three tools run against your real data and a real task, scored on outcomes you set. It replaces the vendor demo, which is scripted to make the tool look good. A proof of concept shows whether the tool works for you.
Why does the buy-a-tool reflex cost money even when the tool is cheap?
Because the licence is the smallest cost. Each new tool adds integration work, overlaps with tools you already run, and spreads your data across one more store. The reflex is what built the sprawl behind the 49% martech utilisation rate. Idle capability is paid-for capability.