guerrilla2799 Martech Stack Audit
Inventory, price, and rule on every tool. Stack sprawl is an accumulation of individually defensible decisions, so only a portfolio-level review catches it.
When to use
- Budget pressure, or a CFO asking questions
- Any renewal above a threshold worth caring about
- Annual planning
- Before adding a tool, to test whether the gap is real
Inputs
- Needs from user: every tool with its annual cost and renewal date, seat counts against seats used, ARR, and who owns each contract
- Reads:
workspace/audit/systems-audit.md
Ask for all of it in one batch. Finance usually has a cleaner list than marketing does, and the gap between the two lists is itself a finding.
Workflow
1. Build the true inventory
Include the things nobody counts: tools on a credit card, tools inside another tool's bill, per-seat tools with unused seats, and anything auto-renewing that nobody owns.
Tool | Category | Annual cost | Renewal date | Seats bought | Seats used | Owner | What it does that nothing else does
The last column is the one that produces the verdict. If it cannot be filled in with a specific capability, that is the answer.
2. Compute the ratio
Stack spend to revenue = total annual martech spend ÷ ARR
| Ratio | Reading |
|---|---|
| Under 4% | Possibly under-tooled, check for manual work that should be automated |
| 4 to 8% | Healthy band at growth stage |
| 8 to 12% | Elevated. There is usually real redundancy |
| Over 12% | Needs a consolidation plan, not a trim |
This is a directional benchmark, not a law. A product-led company with heavy usage-based tooling sits higher for structural reasons.
3. Find the four kinds of dead weight
Redundancy. Two tools doing the same job. Usually the result of a team buying around an unconfigured feature they already own.
Glue. Tools whose primary purpose is moving data between two other tools. Each one is evidence of a seam that was patched rather than fixed. They also add a sync, which adds a place for records to diverge.
Definitional purchases. Tools bought to solve a reporting disagreement. A warehouse will let two dashboards disagree faster and at higher resolution. Check whether the problem was ever technical.
Underutilization. Seats bought against seats used, and tier bought against consumption. This kills more contracts than any other finding, and nobody checks because the invoice is a fixed line item.
4. Apply the add test before any new purchase
State the structural reason the existing layer cannot do this.
If the answer is "it is not configured" → not a purchase
If the answer is "nobody was trained on it" → not a purchase
If the answer is "it genuinely cannot" → proceed to evaluation
Most purchases fail this test, and asking it takes five minutes.
5. Rule on every tool
| Verdict | Meaning |
|---|---|
| KEEP | Does something nothing else does, and is used |
| CONSOLIDATE | Capability exists elsewhere. Migrate and cancel, with a named date |
| CUT | Not used, or the job is no longer worth doing |
| DOWNGRADE | Right tool, wrong tier. Utilization says so |
| ADD | A genuine capability gap that passed the add test |
| HOLD | Cannot decide yet. Name what evidence would decide it and when |
Every verdict carries a dollar figure and a date. A verdict with neither is an opinion.
6. Sequence the cuts by renewal date
Cancellations are easy at renewal and expensive mid-term. Sort the plan by renewal date and put a diary item sixty days before each one, because the week-of conversation always ends in an auto-renewal.
7. Present the savings honestly
Gross annual savings $n
Migration cost, one-time $n (including the hours)
Net year-one savings $n
Net ongoing annual savings $n
Capability lost <name it, or state none>
Name the capability lost. An audit claiming savings with no losses reads as unserious to anybody who has run a migration, and it is the fastest way to have the whole plan dismissed.
Output
- Writes:
workspace/stack/stack-audit.md,workspace/stack/inventory.csv - Uses:
templates/stack-inventory-template.csv - Prints: the inventory, the ratio against the band, the four dead-weight findings, the per-tool verdicts with dollars and dates, the renewal-sequenced plan, and the honest savings table
Rules & quality bar
- Include the tools nobody counts. Credit cards, unused seats, auto-renewals with no owner
- Every tool answers "what does this do that nothing else does"
- Check utilization on every seat-based and credit-based tool
- Run the add test before recommending any purchase
- Every verdict has a dollar figure and a date
- Sequence by renewal date, with a sixty-day diary item
- Name the capability lost. Always
- Never recommend a tool to solve a definitional problem. Route to
reporting-architecture
Related skills
- Pairs with:
credit-and-cost-controlfor usage-based spend - Routes to:
reporting-architecturewhen the problem is definitional,data-model-and-syncwhen it is a seam - See also:
docs/stack.md,docs/field-notes.mdstory 12