The tool audit

You are paying for tools you forgot you own

Open your email right now and search for the word "receipt." Scroll past the grocery runs and the one-time purchases. Look at the recurring charges — the monthly and annual subscriptions that auto-renew without your conscious participation. If you are like most knowledge workers, you will find at least three tools you have not used in the last sixty days, at least two that duplicate functionality you already get from something else, and at least one you genuinely cannot remember signing up for.

This is not a personal failing. It is a structural inevitability of how tools are adopted. You try something during a free trial because a colleague recommended it. You adopt a new project management tool for a specific engagement and never cancel the old one. You sign up for a design app to make one presentation and the annual renewal catches you eleven months later. Each decision was locally rational at the time. None of them were revisited. The result is a tool stack that grew by accretion, not by design — a geological formation of past decisions layered on top of each other, each one fossilized into a recurring charge.

Productiv, a SaaS management platform that analyzes enterprise software usage, reported in their 2023 State of SaaS report that the average company wastes roughly one-third of its software spend on unused or underused licenses. Zylo, a competing platform, found similar numbers — organizations pay for an average of 291 SaaS applications, and roughly 44 percent of licenses go unused in any given month. These are enterprise numbers, but the dynamics scale down perfectly to individual knowledge workers. You are running your own little enterprise, and your procurement department — which is you, making impulse decisions at midnight — has no audit function.

The tool audit is that audit function. It is the practice of periodically sitting down with your entire tool stack and asking three blunt questions about every item in it: Is this still serving a current goal? Is something else in my stack already doing this? And what am I not seeing that I should be worried about?

Systematic review applied to your own infrastructure

The idea of periodically reviewing your operational infrastructure is not new, but most knowledge workers apply it only to their tasks, not to their tools. David Allen, in "Getting Things Done," made the weekly review the keystone habit of his productivity system. Every week, you empty your inboxes, review your project lists, update your next actions, and get current with your commitments. The weekly review is what keeps the GTD system honest — without it, lists decay, commitments slip, and the system gradually diverges from reality. Allen's insight was that a productivity system is not a static structure. It is a living system that requires regular maintenance to stay aligned with what is actually true.

The tool audit applies the same logic one level up. Allen's review asks: "Are my tasks and projects current?" The tool audit asks: "Are the instruments I use to manage my tasks and projects current?" It is the meta-review — the review of the review infrastructure itself. And it is just as necessary, because tools drift out of alignment with your goals just as reliably as task lists do.

W. Edwards Deming formalized this kind of iterative review as the PDCA cycle — Plan, Do, Check, Act — which he popularized in postwar Japan and which became the backbone of the quality management movement. The cycle is simple: you plan a course of action, you execute it, you check whether the results match your expectations, and you act on the discrepancy by adjusting the plan. Then you repeat. The power of PDCA is not in any single cycle but in the repetition — the accumulation of small adjustments that compound into reliable quality over time. Deming argued that organizations fail not because they make bad initial decisions but because they fail to check and adjust. The initial decision fossilizes into permanent practice. The tool audit is the "Check" phase of PDCA applied to your personal infrastructure. Without it, every tool adoption is a one-way door.

Ward Cunningham coined the term "technical debt" in 1992 to describe what happens when software teams take shortcuts that are expedient in the short term but costly in the long term. The metaphor was deliberate — like financial debt, technical debt accrues interest. The longer you leave it unaddressed, the more expensive it becomes to fix. Your tool stack accumulates its own form of technical debt. Every tool you adopt without a clear exit strategy, every redundant subscription you maintain because cancellation feels like a task for another day, every configuration you half-finished — these are all entries on a ledger of tool debt. And like technical debt, tool debt does not announce itself. It silently increases the friction of your daily work until one day you realize that you spend more time managing your tools than using them for their intended purpose.

Waste, cognitive limits, and the courage to subtract

Lean manufacturing, the production philosophy developed at Toyota and articulated by Taiichi Ohno, identifies seven forms of waste — or "muda" in Japanese. Among them are overprocessing (doing more work than necessary), inventory (accumulating more than you need), and motion (unnecessary movement between stations). Applied to your tool stack, these map cleanly. Overprocessing is maintaining a complex tool when a simple one would do. Inventory is the accumulation of unused subscriptions and dormant accounts. Motion is the constant switching between overlapping tools to accomplish tasks that one tool could handle alone.

The lean approach to waste is value stream mapping — tracing the path of a piece of work from beginning to end and identifying every step that does not add value. You can do this with your own workflows. Pick a task you do every week — say, processing your reading notes into your knowledge base. Trace every tool the information touches on its way from raw input to stored note. Your reading app, your highlighting tool, your clipboard manager, your note-taking app, your tagging system. How many of those handoffs are necessary? How many are artifacts of a tool stack that grew without design? Each handoff is a potential failure point, a potential data loss event, and a guaranteed source of friction. The audit reveals these handoffs and asks whether they are adding value or merely adding complexity.

There is a cognitive dimension to this that goes beyond efficiency. Robin Dunbar's research on social group sizes — the famous "Dunbar's number" of roughly 150 stable relationships a human can maintain — offers an analogy for tool relationships. Every tool in your stack is a relationship you maintain. You remember its quirks, its keyboard shortcuts, its update cadence, its pricing changes, its integration points, its failure modes. You hold a mental model of what the tool can do and how it connects to everything else. Each tool occupies cognitive real estate. You cannot maintain deep, productive relationships with an unlimited number of tools any more than you can maintain deep, productive relationships with an unlimited number of people. At some point, adding a new tool does not increase your capability — it fragments your attention across too many interfaces and degrades your mastery of each one.

This is where Marie Kondo's approach to physical decluttering offers a useful structural principle, even if the emotional framing does not quite translate. Kondo's method audits by category, not by location — you gather all your books in one place, all your clothes in one place, and evaluate each category as a whole. The insight is that redundancy is invisible when items are scattered across different rooms. You only see that you own four nearly identical sweaters when you pull them all out of four different closets and line them up. The tool audit works the same way. You do not evaluate tools one by one as you encounter them in your workflow. You pull the entire stack into a single view — every note-taking app, every project manager, every file storage service — and evaluate each functional category as a whole. Only then does the redundancy become obvious.

James Buchanan, who won the Nobel Prize in Economics for his work on public choice theory, formalized the concept of opportunity cost that Adam Smith had hinted at two centuries earlier. Every resource spent on one thing is a resource unavailable for another. Every tool you maintain is energy and attention not spent on the work the tools are supposed to support. The audit forces you to confront opportunity cost directly: is the marginal value of this thirty-first tool greater than the value of the cognitive space I would reclaim by dropping it? The Pareto principle suggests the answer is usually no — roughly eighty percent of your productive output comes from roughly twenty percent of your tools. The remaining eighty percent of your tool stack contributes diminishing marginal value while consuming a disproportionate share of your maintenance budget, both financial and cognitive.

How to run the audit

The tool audit is a structured event, not a vague intention to "clean up my subscriptions sometime." Schedule it quarterly — ninety minutes, recurring, non-negotiable. The cadence matters because it is short enough to catch drift before it compounds and long enough that the overhead of the audit itself is negligible relative to the value it produces.

The audit proceeds in five passes. First, the inventory pass: list every tool you use, including free tools, browser extensions, mobile apps, CLI utilities, and physical tools. Include the tool's primary function, its monthly cost, and the date you last used it. If you cannot remember when you last used a tool, that is information in itself. Second, the usage pass: flag everything untouched in the last sixty days. For each flagged tool, answer one question — do you have a specific, scheduled use for it in the next thirty days? If not, it goes on the removal list. Third, the redundancy pass: group tools by function — note-taking, project management, file storage, communication, design, writing, analytics. For each functional group containing more than one tool, choose a canonical tool and plan migration away from the others. Fourth, the alignment pass: for every surviving tool, verify that it serves a goal you are actively pursuing. Tools inherited from past projects, past jobs, or past interests that no longer map to your current direction get flagged. A tool can be excellent and still be wrong for you right now. Fifth, the risk pass: identify single points of failure. Any tool you rely on daily that has no export function, no backup strategy, and no viable alternative is a risk. Document the risk and either mitigate it (set up exports, identify alternatives) or accept it consciously.

After the five passes, you will have a removal list, a consolidation plan, and a risk register. Execute the removal list immediately — cancel subscriptions, delete accounts, archive data. Schedule the consolidation work as explicit tasks over the following two weeks. File the risk register where you will see it at the next audit. The entire process should take less than ninety minutes. The first audit will take longer because you are building the inventory from scratch. Subsequent audits are updates, not rebuilds, and will be faster.

The Third Brain

AI tools can accelerate every phase of the audit. Feed your tool inventory into an AI assistant and ask it to identify functional overlaps you might have missed — the AI can recognize that your "quick capture" app, your "voice notes" app, and your "read-later" app are all performing variations of the same intake function. Ask the AI to research alternatives for your single-point-of-failure tools, including feature comparisons, export capabilities, and pricing. Use it to draft cancellation messages for the subscriptions you are cutting, to generate a migration checklist for consolidating from two note-taking apps into one, or to estimate the annual cost savings from your removal list.

But the judgment calls remain yours. The AI does not know which tool has the workflow integration that saves you twenty minutes a day. It does not know that you chose this particular Markdown editor because it handles your specific Zettelkasten linking syntax. It does not know that the "redundant" second project management tool is the one your collaborators are on, and dropping it would mean dropping the collaboration. The AI handles inventory, comparison, and calculation. You handle context, priority, and the final decision about what stays and what goes.

The bridge to purpose

The tool audit is a hygiene practice — necessary, clarifying, and slightly uncomfortable in the way that all honest self-assessment is uncomfortable. It forces you to confront the gap between what you intended your tool stack to be and what it actually became. It reveals the tools you adopted out of curiosity rather than need, the subscriptions you maintained out of inertia rather than value, and the gaps you tolerated out of unawareness rather than choice.

But the audit is a means, not an end. The purpose of reviewing your tools is not to have fewer tools or cheaper tools or more elegant tools. The purpose is to ensure that your tools serve your goals — that the infrastructure exists to support the work, not the other way around. This is the distinction that the next lesson, Mastering tools is not the point, makes explicit: mastering tools is not the point. The point is the thinking, the creating, the building, the contributing. Tools are the scaffolding, not the structure. The audit keeps the scaffolding from becoming the project.

---

Sources:

1. Allen, D. (2001). Getting Things Done: The Art of Stress-Free Productivity. Viking Press.
2. Deming, W. E. (1986). Out of the Crisis. MIT Press.
3. Cunningham, W. (1992). "The WyCash Portfolio Management System." OOPSLA '92 Experience Report.
4. Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
5. Dunbar, R. I. M. (1992). "Neocortex size as a constraint on group size in primates." Journal of Human Evolution, 22(6), 469-493.
6. Kondo, M. (2014). The Life-Changing Magic of Tidying Up. Ten Speed Press.
7. Buchanan, J. M., & Thirlby, G. F. (1973). L.S.E. Essays on Cost. London School of Economics.
8. Productiv. (2023). The State of SaaS Spend and Usage Report.
9. Zylo. (2023). SaaS Management Index: Annual Report on SaaS Trends.