The MarTech Stack Nobody Needs: A Field Guide to Over-Engineering

I audited a MarTech stack once that had three tools doing session replay. Not three tools that each did something slightly different — three tools with near-identical feature sets, each purchased by a different team in a different quarter, each still being paid for because nobody wanted to be the one to cancel a tool someone else might be using.

That's the pattern almost every over-engineered stack follows: no single decision was unreasonable. A team evaluates a tool, it solves their immediate problem, they buy it. Repeat across six teams over three years and you end up with a stack that's individually defensible and collectively absurd.

The audit question that actually finds the waste

"What does this tool do" is the wrong question — every tool in the stack has an answer to that, usually a good one. The question that finds real redundancy is: "what data does this tool need that no other tool in the stack already has, and could get to without a new integration?" Asked that way, the session-replay triplicate collapses immediately, because all three needed the same event stream and none of them needed anything the others didn't already have access to.

Every tool in an over-engineered stack can justify its own existence. Almost none of them can justify existing next to the others.

Three patterns that produce redundant stacks

• Team-level procurement with no central registry — different teams solve the same problem independently because nobody can see what's already purchased.
• Tool evaluation that stops at "does it solve my problem" without asking "does something we already pay for solve 80% of this" — the remaining 20% rarely justifies a whole new contract.
• No sunset trigger — tools get added constantly but almost never get formally reviewed for removal, so the stack only grows.
• Vendor lock-in disguised as convenience — a platform's bundled feature gets used instead of a dedicated best-in-class tool, then the dedicated tool gets kept anyway 'just in case', and now you're paying for the capability twice.

What a real audit produces

A useful MarTech stack audit doesn't end with a slide of logos and a cost total — it ends with a decision for every tool: keep, consolidate, or cut, with the data dependency that justifies it. If a tool's justification is "the team likes the dashboard" rather than "it's the only source for this specific data," that's a consolidation candidate, not a keep.

For each tool, answer:
1. What unique data does it need that nothing else in the stack has?
2. If removed, what would actually break (not "what would someone miss")?
3. Could an existing tool's underused feature replace it?

No clear answer to #1 and #2 → consolidation candidate.

The uncomfortable part of this exercise is political, not technical — someone championed every tool you're now recommending cut. The audit's job isn't to assign blame for reasonable decisions made in isolation; it's to make the stack's actual shape visible, since nobody designed it on purpose and nobody can fix what they can't see.