Start with the last time it was useful
Choose one recurring workflow, such as joining a call or collecting research notes. List the tools involved and the last concrete job each one performed. “It might be useful” is a hypothesis; “it is the fallback when this connection fails” is a role you can inspect.
For each item, finish this sentence: “Without it, I could not…” If you cannot name an outcome, mark the role unclear. That is a reason to investigate, not permission to delete the tool immediately.
Separate duplicates from deliberate backups
Two tools doing similar work are not necessarily redundant. One may be an intentional fallback. The useful distinction is whether someone can explain when the second tool is used and how to switch to it.
Imagine two note apps. If one receives meeting notes and the other stores research, they may have distinct roles. If the same notes are copied between both because nobody completed an earlier migration, the duplicate workflow deserves a closer look.
Give the maintenance a name
Next to each job, record who handles configuration, updates and failure. For a personal setup, that person may always be you. The table still exposes how many small responsibilities the setup creates.
For a shared workflow, use a named owner and keep sensitive details in the approved internal system. An inventory should point to the information needed to recover; it should not become a public collection of credentials.
Try one reversible removal
Choose one item with an unclear or duplicate role. Check what depends on it, keep a fallback, and leave it out of one normal work cycle without deleting data or cancelling an essential service. Record what you actually miss.
Keep it if a real job reappears. Retire it only when the job is covered and the dependencies are understood. The goal is an explainable setup, not a smaller object count for a photograph.
Job-first tool audit
| Tool | What stops without it? | Owner | Next experiment |
|---|---|---|---|
| Primary tool | A named work outcome | Who maintains it | Keep and document the role |
| Possible duplicate | Unclear or already covered | Who checks dependencies | Leave out of one work cycle with a fallback |
| Deliberate backup | Recovery when the primary fails | Who knows how to switch | Check that the fallback still works |