The Quarterly Stack Audit That Takes Ninety Minutes and Has Never Not Paid For Itself

The reason most software audits do not happen is that they are framed as a project. Someone proposes cataloguing every tool, interviewing every user, and building a matrix, and the whole thing dies at the interview stage. The version I run takes ninety minutes on a Tuesday afternoon four times a year, and the constraint that makes it work is that every line must end in a decision before I move to the next one.

Start with the bank statement, not the tool list. This is the single most important departure from how it is usually done. A list of tools is a list of things you remember; a statement is a list of things that are actually charging you. Export twelve months of card and account transactions, filter for anything recurring — listing every recurring charge is the whole first step — and you will find between three and seven things you would not have written down. In the last four audits I have found a defunct transcription service, a second seat on a tool we already had, a domain privacy add-on renewing at four times its first-year rate, and a form builder that a former contractor signed up for on our card.

Put every recurring charge in one sheet with four columns: what, how much a year, who uses it, and when it renews. Do not add more columns. The temptation is to score things on value or criticality, and every scoring system I have tried has turned into a way of deferring the decision. Four columns, then decide.

For each line, there are exactly three outcomes and you must pick one. Keep, which means you would buy it again today at that price. Cut, which means cancel now and accept whatever you lose, even if you still like it. Or downgrade, which is the one people forget and which is where most of the savings actually live — a tier you no longer need, seats you no longer fill, an annual plan you should be on or should not be, since annual discounts are really loans.

The “who uses it” column is where you will lie to yourself, so make it specific. Not “the team” but a name. If you cannot name a person who opened it in the last month, the answer is cut or downgrade, and if you are uncertain, most tools will tell you: look for a members or activity page showing last login. Twice I have found tools where the last login for every seat was more than sixty days old, which is a very clear signal and a slightly embarrassing one.

Handle the renewal date column by putting each one in a calendar as an event thirty days before, titled with the amount. This is the part that compounds. The reason a bad subscription survives is that the decision point arrives as a receipt, after the money is gone. Moving it thirty days earlier turns it into a decision you can act on, and after a year of doing this the audit itself gets shorter because the obvious cuts have already happened at their own renewal points.

Our results across four audits: $2,140 of annual spend cut, $1,315 downgraded rather than cut, and — this is the part I did not expect — two tools upgraded, because the audit surfaced that we were working around a limitation we could have paid a small amount to remove. An audit is not only a cost-cutting exercise — and when it cannot settle a line, a week without the tool can — and framing it purely that way makes people defensive about their tools, which makes them hide them, which is how you end up with a stack you cannot see.

One rule I would add for anyone doing this in a team rather than alone: run it on spend, present it as decisions, and never present it as a list of things individual people were wrong to buy. The first time I did this I got the tone wrong, and the result was that the next quarter’s statement had two new charges on personal cards being expensed as “software,” which is worse in every way than the thing I was trying to fix.