Tool minimalism

The eighty-app problem

The average enterprise employee now uses between eighty and one hundred distinct software applications in the course of their work. That number comes from Okta's 2023 "Businesses at Work" report, which tracked application deployment across thousands of organizations. Productiv's independent research found similar figures, noting that large enterprises deploy an average of 364 SaaS applications — though individual employees typically touch a fraction of that total. Even at the individual level, the number is staggering: a knowledge worker switching between applications an average of 1,200 times per day, according to research from Harvard Business School.

You probably think you are different. You are a thoughtful practitioner. You have been through the earlier lessons in this phase — choosing tools deliberately (Tool selection criteria), learning them deeply (Learn your tools deeply), arranging them into a coherent stack (The tool stack), and ensuring they interoperate (Tool interoperability). Surely your stack is lean and intentional.

Count them. Open your phone and scroll through every installed app. Open your browser and look at every extension. Open your laptop and check every application in your dock, your menu bar, your startup items. Count the SaaS tools you log into — the note apps, the task managers, the calendars, the communication platforms, the file storage services, the project management tools, the read-later apps, the bookmarking tools, the habit trackers, the time trackers, the writing tools, the design tools. Most people who do this exercise honestly arrive at a number between twenty-five and fifty. Many arrive higher. The question this lesson asks is simple and uncomfortable: do you need all of them?

The cognitive cost of every tool you own

Each tool in your stack imposes a cost, and that cost is not primarily financial. It is cognitive. Understanding why requires a brief excursion into how your brain processes choices and manages complexity.

In 2000, psychologists Sheena Iyengar and Mark Lepper published a study that became one of the most cited findings in behavioral science. They set up a tasting booth at a grocery store, alternating between offering six varieties of jam and twenty-four varieties. The large display attracted more people to stop and look. But when it came time to actually buy, customers who had seen the smaller display were ten times more likely to purchase. More options did not lead to better decisions. They led to paralysis. Barry Schwartz formalized this observation in his 2004 book "The Paradox of Choice," arguing that beyond a certain threshold, increasing the number of available options does not increase satisfaction — it decreases it. More choices means more comparison, more regret about unchosen alternatives, and more cognitive effort spent deciding instead of doing.

This applies directly to your tool stack. Every tool you own is an option. Every time you encounter a task — take a note, schedule a meeting, capture an idea, track a project — your brain runs a micro-decision: which tool should I use for this? If you have one note-taking app, the decision is automatic. If you have three, the decision is a cognitive event. Which app is best for this type of note? Where will I be able to find it later? Does this note belong in the long-form app, the quick-capture app, or the structured database app? The decision takes seconds, but it interrupts your flow, and it happens dozens of times a day.

William Edmund Hick and Ray Hyman formalized this in 1952 with what became known as Hick's Law: the time required to make a decision increases logarithmically with the number of available choices. Double the number of tools in your stack and you do not double your decision time — but you measurably increase it for every tool-selection decision you make. Across hundreds of daily micro-decisions, the cumulative drag is substantial.

The cost extends beyond decision time. George Miller's seminal 1956 paper, "The Magical Number Seven, Plus or Minus Two," established that working memory can hold approximately seven chunks of information simultaneously. Every tool in your active stack occupies a chunk — not constantly, but recurrently, as you remember where things are stored, which tool has which capability, and what the current state of each tool's inbox looks like. A twenty-tool stack does not just slow your decisions; it taxes the working memory you need for actual thinking.

John Sweller's cognitive load theory, developed through the 1980s and 1990s, distinguishes between intrinsic cognitive load (the inherent difficulty of the task) and extraneous cognitive load (the difficulty imposed by the environment in which you perform the task). Your tools are supposed to reduce extraneous load — to make tasks easier by offloading memory, computation, and organization to external systems. But every unnecessary tool adds extraneous load back in: the load of choosing, switching, maintaining, and integrating. At some point — and most knowledge workers passed that point years ago — the tools themselves become the primary source of extraneous cognitive load. The instruments meant to help you think become the things preventing you from thinking.

The minimalist tradition, from Unix to Kondo

The idea that less can be more is not new, but it has been independently rediscovered across remarkably different domains.

In computing, the Unix philosophy — articulated by Doug McIlroy at Bell Labs in the early 1970s and documented by Eric Raymond in "The Art of Unix Programming" — insisted that each program should do one thing and do it well. The entire Unix ecosystem was built on small, focused tools composed through pipes. The power came not from any individual tool's feature richness but from the ability to chain simple tools into complex operations. The philosophy was explicitly minimalist: do not build a tool that does ten things poorly when you can build ten tools that each do one thing superbly. The modern implication is that your stack should follow the same principle — each tool justifying its existence through a specific, well-defined function that no other tool in the stack handles better.

In personal life, Marie Kondo's 2011 book "The Life-Changing Magic of Tidying Up" proposed a deceptively simple question for every possession: does it spark joy? The question forces an evaluation that bypasses rational justification (which can always construct a reason to keep something) and goes directly to utility and resonance. Applied to your tool stack, the adapted question is: does this tool actively serve my work, or am I keeping it because I might need it someday? The "might need it someday" tools are the digital equivalent of the clothes in the back of your closet — they consume space, create clutter, and produce a background anxiety about things you own but do not use.

Cal Newport, in his 2019 book "Digital Minimalism," went further. He proposed a philosophy of technology use built on a single principle: start from zero and add tools only when they serve something you deeply value, and only when they are the best way to serve that value. This is the opposite of how most people build their tool stacks. Most people start with whatever tools are available, add new ones whenever they encounter an interesting feature or a compelling recommendation, and never subtract. The stack only grows. Newport's framework inverts this: the default state is no tools, and each addition must clear a high bar of justification.

Nassim Nicholas Taleb's concept of the Lindy effect, explored in "Antifragile" (2012), adds another dimension. The Lindy effect holds that for non-perishable things — technologies, ideas, books — expected future lifespan is proportional to current age. A tool that has been useful for twenty years is likely to remain useful for another twenty. A tool released six months ago has no such track record. This does not mean new tools are bad. It means that old, proven tools deserve a durability premium in your evaluation. Plain text files, spreadsheets, email, the command line — these have survived decades of technological change precisely because they solve fundamental problems in robust ways. The shiny new app may or may not still exist in three years. Markdown will.

The integration tax and the switching cost

Tool minimalism is not merely an aesthetic preference. It is a strategic response to two real costs that scale with the size of your stack: the integration tax and the switching cost.

The integration tax is the ongoing effort required to keep your tools connected. In the previous lesson, you learned about interoperability — the ability of tools to exchange data. But even well-integrated tools require maintenance. APIs change. Automations break. Sync conflicts arise. The more tools in your stack, the more integration points exist, and each integration point is a potential failure mode. If you have five tools with full interoperability, you have up to ten pairwise connections to maintain. If you have fifteen tools, you have up to one hundred and five. The integration tax grows quadratically with the number of tools. Minimalism is not just about simplicity — it is about reducing the combinatorial explosion of connections that a large stack demands.

The switching cost is the cognitive price you pay every time you move from one tool to another. Gloria Mark's research at the University of California, Irvine, found that the average knowledge worker switches tasks every three minutes and five seconds, and that it takes an average of twenty-three minutes and fifteen seconds to fully resume a task after an interruption. Tool switches are a subset of task switches — every time you leave your text editor to check your task manager, leave your task manager to update your calendar, leave your calendar to respond in your chat app, you are paying the switching tax. Fewer tools means fewer switches. Fewer switches means more sustained attention on the work itself.

There is a compounding effect here that most people miss. When you reduce your stack from twenty tools to eight, you do not simply eliminate twelve tools. You eliminate the hundreds of daily micro-decisions about which tool to use. You eliminate the maintenance burden on twelve sets of configurations, updates, and login credentials. You eliminate the mental model overhead of remembering twelve different interfaces, twelve different organizational structures, twelve different search mechanisms. The cognitive savings are not linear — they are superlinear, because each eliminated tool removes not just itself but its web of interactions with every other tool in the stack.

Warren Buffett's two-list strategy applied to tools

Warren Buffett reportedly advised his personal pilot, Mike Flint, using a simple prioritization exercise. First, write down your top twenty-five goals. Second, circle the five most important. Third — and this is the critical step — treat the remaining twenty as your "avoid at all cost" list. Not a "get to when I can" list. An active avoidance list. The logic is that the twenty items that are good-but-not-great are the most dangerous, because they are attractive enough to consume your time and attention without delivering your highest-value outcomes.

Applied to your tool stack, the two-list strategy works like this. List every tool you use. Circle the five that are genuinely indispensable — the ones that, if everything else vanished, would still let you do your most important work. For most knowledge workers, this core set is something like: a text editor or note system, a calendar, a communication tool, a browser, and one domain-specific tool (a code editor for developers, a design tool for designers, a spreadsheet for analysts). Those five are your priority. Everything else is your avoidance list — not because those tools are useless, but because the cognitive overhead of maintaining them actively competes with the deep use of your core tools.

The insight is subtle and counterintuitive. The tools you should fear most are not the obviously bad ones — you will discard those naturally. The dangerous tools are the pretty good ones. The note-taking app that is slightly better for one specific use case. The project manager that has one feature your primary tool lacks. The automation platform that could save you twenty minutes a week if you spent four hours configuring it. Each one, individually, seems to justify its place. Collectively, they fragment your attention, multiply your integration tax, and prevent you from achieving the deep mastery of your core tools that would deliver far more value than any marginal feature ever could.

How to practice tool minimalism without becoming a Luddite

Tool minimalism is not technophobia. It is not a rejection of new tools or an insistence on using outdated ones. It is a discipline of intentional selection — a commitment to evaluating every tool against the question: does the value this provides exceed the total cost of adding it to my stack?

The total cost includes the obvious expenses — subscription fees, setup time, learning curve — but also the hidden ones: the cognitive overhead of one more login, one more interface to remember, one more inbox to check, one more integration to maintain, one more place where data might be but also might not be. When you account for the full cost, most candidate tools fail the evaluation. They solve a real problem, but the problem is not severe enough to justify the ongoing tax.

Practically, tool minimalism follows three principles. The first is consolidation: before adding a new tool, ask whether an existing tool in your stack can absorb the function, even imperfectly. A note-taking app that handles tasks at 80% effectiveness is better than a dedicated task app at 100% effectiveness plus the overhead of maintaining a second tool. The 20% gap in task functionality is almost always smaller than the switching cost, the integration tax, and the cognitive overhead of the additional tool.

The second principle is the trial period with an exit date. When you do evaluate a new tool, give it a defined trial — two weeks, a month — with a specific criterion for success. "If this tool saves me thirty minutes per week by the end of the trial, it stays. If not, it goes." Without an exit date, trial tools become permanent residents. They accumulate like browser tabs you will get to someday.

The third principle is regular pruning. Set a quarterly review — it can coincide with your tool stack audit from The tool audit — where you examine every tool you use and ask: have I used this in the last month? If not, it goes. Has the problem this solves changed? If so, reassess. Could a Tier 1 tool now handle this function due to updates or my improved skill? If so, consolidate. The stack should shrink over time as your skills with your core tools deepen and those tools absorb functions that once required dedicated applications.

The Third Brain

AI tools present both the greatest opportunity and the greatest risk for tool minimalism.

The opportunity is consolidation. A capable AI assistant can absorb functions that previously required separate tools: summarization (replacing your read-later app's digest feature), format conversion (replacing dedicated file converters), brainstorming (replacing mind-mapping tools), scheduling assistance (reducing calendar management overhead), and lightweight coding (replacing some browser extensions and automation scripts). A single AI interface can collapse multiple single-purpose tools into one general-purpose conversation. This is genuinely powerful and aligns perfectly with the minimalist principle of fewer tools covering more functions.

The risk is proliferation. The AI tool ecosystem is expanding explosively — new wrappers, new interfaces, new specialized agents appearing daily. It is tempting to adopt an AI tool for every specific function: one for writing, one for coding, one for research, one for image generation, one for data analysis, one for email management. But this is the same sprawl pattern that this lesson warns against, just dressed in newer technology. The minimalist response is the same: choose one or two AI tools that cover the broadest range of your needs, learn them deeply, and resist the pull of every specialized alternative. The cognitive cost of maintaining five AI subscriptions, five different interaction models, and five different capability boundaries almost certainly exceeds the marginal capability gains of specialization.

The bridge to building

There is a tension in tool minimalism that the next lesson resolves. Sometimes, the reason your stack has grown is that no commercially available tool does exactly what you need. You cobble together three tools to approximate a workflow that a single custom tool could handle perfectly. The minimalist response might be to tolerate the imperfect approximation. But there is another option: build the tool yourself.

This is the domain of the next lesson — build versus buy (Build versus buy). When does the investment of building a custom tool, tailored precisely to your workflow, justify the cost? When does a small script, a personal automation, or a bespoke application actually reduce your stack size by replacing three commercial tools with one handmade one? The minimalist stack is not always the one with the fewest purchased tools. Sometimes it is the one where a single custom creation eliminates an entire category of commercial compromise.

But before you build anything, internalize the core principle of this lesson: your tool stack should be as small as possible and no smaller. Every tool earns its place through demonstrated, ongoing value — not through theoretical utility, not through sunk cost, and not through the seductive promise that this one will finally be the app that makes everything click. Fewer tools, deeply mastered and tightly integrated, will outperform a sprawling collection every time. The goal is not to have the best tools. The goal is to do the best work. And the best work happens when your tools are invisible — so deeply integrated into your practice that you forget they are there, and all that remains is you and the thinking.

---

Sources:

1. Schwartz, B. (2004). The Paradox of Choice: Why More Is Less. Ecco/HarperCollins.
2. Iyengar, S. S., & Lepper, M. R. (2000). "When choice is demotivating: Can one desire too much of a good thing?" Journal of Personality and Social Psychology, 79(6), 995-1006.
3. Newport, C. (2019). Digital Minimalism: Choosing a Focused Life in a Noisy World. Portfolio/Penguin.
4. Hick, W. E. (1952). "On the rate of gain of information." Quarterly Journal of Experimental Psychology, 4(1), 11-26.
5. Miller, G. A. (1956). "The magical number seven, plus or minus two." Psychological Review, 63(2), 81-97.
6. Sweller, J. (1988). "Cognitive load during problem solving: Effects on learning." Cognitive Science, 12(2), 257-285.
7. McIlroy, M. D. (1978). "Unix Time-Sharing System: Foreword." The Bell System Technical Journal, 57(6), 1899-1904.
8. Raymond, E. S. (2003). The Art of Unix Programming. Addison-Wesley.
9. Kondo, M. (2011). The Life-Changing Magic of Tidying Up. Ten Speed Press.
10. Taleb, N. N. (2012). Antifragile: Things That Gain from Disorder. Random House.
11. Mark, G., Gudith, D., & Klocke, U. (2008). "The cost of interrupted work: More speed and stress." Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 107-110.
12. Okta. (2023). Businesses at Work Report.