The "Tool-To-Rule-Em-All" Fallacy

Why Modular Systems Trump Shiny Monoliths In The Long Run

Would you ever fry eggs in your bathroom or shit directly into your bed?

Of course not—because you instinctively understand that each room in your home serves a specific purpose. You don’t want nasty smells in your bed or leftover food next to the toilet. Instead, you prefer each room be dedicated to specific “jobs.”

Though your home is made of concrete and fixed in shape, it’s still divided into distinct parts with clear functions and boundaries. Each room signals what belongs there and what doesn’t. And whenever you physically enter a room, your mental setup follows. It’s easier to sleep in an actual bedroom and work in a separate home office than if everything were mashed with no clear boundaries.

All rooms are connected in a typical home arrangement, yet they remain somewhat isolated, linked only by a single door. One advantage of this “modular” setup is that you can easily repurpose individual parts. For example, you might turn a fitness room into a nursery when a little one arrives. This is much harder to do if you live in a one-room apartment or a big studio, where it’s often unclear where one part ends and the next begins—physically, but more importantly, mentally. While you can create different corners for different purposes, it’s not the same as having distinguishable rooms.

To be clear, there’s a time for gluing things together and combining multiple functions into one. Take smartphones, for example. Over the years, they’ve successfully replaced many tools in my life: landline phones, cameras, clocks, flashlights, maps, compasses, and more. Except for a flashlight in my attic, I no longer own dedicated devices for these functions. The smartphone has packed all this functionality into a tiny, portable device and totally replaced these other tools.

And yet, if I were embarking on an adventurous trip through a jungle, I’d opt for separate and specialized tools instead of relying solely on my smartphone. In such a scenario, I’d trust a setup composed of multiple reliable tools over a single, highly entangled multi-functional device. The most apparent reason? If the smartphone dies, I’m left stranded. Sure, I could take several smartphones and stock up on power banks, but I’d still be dealing with the inferiority of each individual tool. The battery of a real watch and a real flashlight lasts much longer than those in a smartphone.

Put this way, the benefits of systems with separate, standalone tools seem like a no-brainer. And yet, the allure of the “all-in-one solution” continues to captivate people, especially in the digital realm. People often find themselves drawn to all-encompassing master tools like Notion in search of the one app “to rule them all”—the ultimate solution that will let them abandon dozens of separate and specialized tools and thus simplify their lives greatly.

In today’s essay, I will discuss why this approach is misguided; detrimental, even. I want to explore the numerous advantages of modular systems over the flawed alternative: monolithic (“all-in-one”) arrangements, like those found in a Swiss Army knife or an app like Notion. While monolithic systems, whether physical or digital, conveniently encapsulate numerous—sometimes hundreds—of functions into one object or platform, they come with severe trade-offs that one should be aware of. And in most cases, one should avoid them whenever possible.

The Shiny Monolith

A monolith is a system in which all components and functions belong to a single module. It is essentially a system without modularization. It’s a structure with no separate parts, just one cohesive whole, where everything’s mixed together.

A monolith isn’t inherently evil; sometimes, it’s precisely what we want. Especially in the physical realm, having multiple functions packed into one physical item can be incredibly appealing. For example, until about a year ago, I lived in a relatively small apartment without space for a washing machine and a dryer in the bathroom. However, I squeezed a single machine into the kitchen that combined washing and drying. Now, this had some drawbacks. The drying wasn’t perfect, and I had to hang my laundry afterward anyway. Worse, every now and then, my coffee machine, located right on top of the washer, could spill over my laundry. But at least it enabled me to condense everything into the smallest possible arrangement and made my towels much smoother. Plus, it was certainly more budget-friendly than buying two separate devices and moving to a bigger apartment.

An older and perhaps more vivid example of a monolith is the Swiss Army knife. It packs a knife, a corkscrew, a bottle opener, a toothpick, and more into a neat gadget. Highly appealing when camping and again without much physical space to spare. However, you’re unlikely to use a Swiss Army knife to cut bread, slice sausage, or open a bottle at home. For those tasks, you probably have dedicated, more effective tools.

However, the most prominent monolith in our lives today is the smartphone, which combines hundreds of functions that fit right in our pockets. On the one hand, this is a remarkable technological achievement. On the other hand, this convenience comes with a price. Our smartphones are incredibly versatile, but none of their numerous functions is exceptionally good. And all of its power is immediately gone once we run out of juice. The same goes for that washer-dryer combo and the Swizz Army knife—they are functional but not necessarily excellent at any of the jobs they serve.

This highlights our first key point: monoliths come with trade-offs. There’s always a price to pay for the convenience we get from them.

---

Now, whether something qualifies as a monolith or a modular system depends on our perspective. In the examples above, we viewed various devices from a black-box perspective that a user of these systems has. We focused on the functionality these tools deliver without peeking inside. However, when we talk about modules and monoliths, we can also take a more “white-box” approach, examining the internal workings of these devices. And here, things might look different, which can make a difference.

For instance, if you open up a washer-dryer, you might struggle to distinguish which parts are responsible for washing and which are for drying—some components may even serve both purposes. So, in this case, we can say that the device is a monolith through and through. On the other hand, when you open your Swiss Army knife, the internal structure is somewhat more structured. Some tools might combine functions (like a bottle opener that works booth for beer and wine bottles), but you can clearly distinguish several parts of the knife. So, from an inside perspective, the Swiss Army knife isn’t a pure monolith anymore; it contains discernible modules.

What about the smartphone? Here, things get even trickier. While certain features, like the flashlight and camera, might be detachable, others, such as the gyroscope, are often invisible to the untrained eye. Many of these features are fused into a single circuit board, and worse yet, most functionalities aren’t even based on hardware. If you open your smartphone, you cannot tell where the part responsible for the “maps app” or the one that allows you to use “TikTok.” Instead, all the apps are driven and separated by software—programs and apps that leverage the same underlying hardware to deliver different capabilities. Because of this, smartphones are so much more successful than traditional all-in-one tools. The essence of software is that it is “soft” in the sense that it is “easier to change.” Unlike the physical boundaries that arise from the rooms of a house, in good software, almost everything can be shaped and changed completely. So, in a certain way, many problems of the monolith were circumvented by moving the problem to another level of abstraction. However, the problem wasn’t fully resolved. Because just like hardware, software can also be composed either in a modular fashion or it can be monolithic. So, while a smartphone’s hardware is somewhat monolithic, its software introduces a whole new level of complexity. In software, it’s often even harder to tell modules apart. There are no visible pipes or cables—just lines of code. In code bases, modularity can arise, for instance, from the fact that there are separate “files” and “bundles of files” and that these don’t know about each other. However, this type of separation is much harder on our cognitive apparatus than discerning modules in the physical world. And it certainly doesn’t help that all the code, once written in such a file-based and more human-readable format, is eventually transformed into a single “monolithic mess” that the computer actually understands and can execute; it all just further blurs the boundaries of it all.

While a software monolith doesn’t take up physical space like the hardware monolith, the advantage of the software monolith lies elsewhere: it can be faster and easier to build and thus less expensive in the short term. Again, the monolith provides convenience. Yet, the differences and trade-offs between software modules and software monoliths mirror those in hardware. A monolith might get many jobs done, but excellence is usually found in separating code into specialized and dedicated modules. Again, much relates to how our brains work and the fact that modularizing code makes our cognition easier. Because as the software monolith grows, maintaining clear separations of concern becomes increasingly difficult. A software monolith can be well-structured and organized, but it’s much harder to achieve separation through concepts and rules than it is through physically enforced boundaries like the walls of a house that we have in the physical world. If the structure isn’t “physically” enforced by rigid boundaries between separate modules, those boundaries must be created through rules and disciplined adherence. Again, that’s a burden on the mind. And it becomes increasingly difficult as a software system grows.

Here's a second insight: the modules vs. “all-in-one” question can be moved up from hardware to software, and by doing so, many of the downsides of the hardware monoliths disappear. However, this only shifts the problem, as the software monolith has different downsides.

---

Another way to look at software is to shift back to a black-box perspective. Just as we saw with washer-dryer combos and Swiss Army knives, the digital realm sees a trend of putting a lot of functionality together into one thing. Apps like Facebook and WeChat have grown to encompass a staggering number of mini-apps and features, expanding far beyond their original scope instead of building many separate apps for separate features. For me, the most concerning hype in recent years was the approach to get “everything into the browser,” which, fortunately, seems to be waning.

Regardless of how they are built on the inside, from a user perspective, software monoliths again may do several things okay or even well, but they certainly don’t excel at any of them. Having learned a bit about the internal side of things, we can also say that if the monolithic nature also appeared inside an app, that app would likely be more costly and harder to maintain and develop further. Entropy will eventually kill all apps, but the ones built in a monolithic fashion are first.

Notion is the scapegoat of this essay, and while it is a monolith through and through from the outside, I have reason to believe that, at least on the inside, it isn’t. So that’s about the only good thing I have to say about it here.

---

Whether driven by physical space constraints, practicality, production costs, or marketing reasons, the push toward monoliths is evident across various domains. The effect seems to be always the same: it’s a matter of convenience that steers us away from excellence. True excellence is found in dedicated modules, not in monoliths.

A shiny monolith can convince us that an “all-in-one solution” is ideal, even when more specialized and dedicated tools are available. Consider again the washer-dryer combo in a small apartment or the Swiss Army knife on a camping trip—one might argue that these are valid use cases for monolithic solutions. But if I had enough space and money, a separate dryer would undoubtedly be superior to the combo, and I certainly wouldn’t use my Swiss Army knife at home. I would almost always choose dedicated, separate tools instead, and you would, too. And yet, in the digital realm, we observe a different trend: people are increasingly trying to consolidate their tools into monolithic systems.

In German, there’s an amusing term for such shiny monoliths: Eierlegende Wollmilchsau (“egg-laying wool-milk-pig”). It refers to an imaginary animal that combines the best features of a chicken, sheep, cow, and pig into one creature. You can see my somewhat failed attempt to visualize it in the title image for this essay. That I wasn’t able to get LeonardoAI to make it any better, is somewhat fitting. This hybrid creature, dating back to a poem from 1959, symbolizes something that seemingly “has only advantages, satisfies all needs, and meets all demands,” yet is ultimately unrealistic or, in our case, unsustainable.

The Price for All-In-One Solutions

In the context of Fractal Productivity and the world of Personal Knowledge Management (PKM), Notion is by far the biggest contender for being a shiny monolith. Due to this, I’ve mockingly called it a “knitted castle.” It’s so tightly integrated that if we untie one part, the whole thing unravels.

Upon further contemplation, however, it might be even more appropriate to call it an egg-laying wool-milk pig. To see why that is, let’s look at what people expect from it:

• A smoother integration of “everything” with no flow breaks: The big idea is that all provided functions work seamlessly together as they are from the same company and created in a way that one doesn’t need any external connectors or workarounds that make one’s system more complex and that can only break.

• A harmonious overall product with smart internal structure: The tool feels cohesive, with no “hacky stitches” needed to make different parts work together. It is all integrated and accessible from everywhere.

• “Everything” in one place: One can easily create a “life dashboard” that tightly integrates all use cases into a single platform. You can conveniently see all your appointments, tasks, and notes for the day in one place.

• Same Data, Multiple Perspectives: Since everything is so tightly integrated, you can look at your data from multiple angles. The same data can be shown in a calendar, a list, a database, or a Kanban board. So why would one ever go with separate tools that are not integrated instead?

• A single app that leads to quick learning and less maintenance: You need to install just a single app. There’s only one tool to learn, pay for, and maintain, with no need to add “glue” between different tools. And to make things even faster, you can buy and use pre-built “done-for-you” Notion setups to get you started quickly without much setup or thinking.

While these benefits seem like valid reasons — one might say, they even seem too good to be true — let’s now consider the trade-offs and price we pay for these conveniences:

• There is a single point of failure: An all-in-one tool poses a significant concentration risk. If it suddenly becomes much more expensive, or the product is discontinued or not maintained, you’re left in a precarious situation. We wouldn’t pick the smartphone for the jungle adventure, so why would we choose a Notion kind of tool for all productivity needs?

• There is a total vendor lock-in: Transitioning out of an all-in-one tool is far more challenging than simply replacing a single module, especially if that tool keeps your data prisoner. It is also quite likely that no valid alternative is even available in such a situation, so you are left, at once, on your own devices.

• You go all-or-nothing: You might end up with a lot of unused functionality because the all-in-one tool does “everything,” but you need only so little. You can’t remove what you don’t need, so in the worst case, it even gets in your way through convoluted user interfaces. And in the best case, it only slows down the whole app.¹ In other words, even the functions you don’t use still can impact you!

• You have a lot less customizability: While it often may appear as though you have more options with a monolith, the reality is that the tool is often more opinionated and less flexible than it seems. For example, in a tool like Notion, you have one major way to do task artifact management. In a modular system, you can pick the most appropriate among dozens of task managers, all with slightly different philosophies and feature sets.

• Inability to replace individual components: If one part of the tool doesn’t fit your needs, you can’t simply swap it out—this is the “knitted castle” problem. In a modular house, you can replace a single room. You may need to move to another place entirely to achieve the same with a monolith.

• Lack of clear separation: There’s no apparent physical or logical separation of things—for example, tasks and notes are often not distinguished. While some see this as an advantage, it can quickly become a curse.

These are just as many, if not more, reasons not to use a tool like Notion. Of course, the decision isn’t black and white; it’s a matter of trade-offs. A person with a small apartment might not have room for two separate washing devices. Similarly, someone less technically inclined or more visually oriented might not have the patience or “head space” to manage and set up 20 different tools instead of just one. But it’s important to realize that, just as a washer-dryer won’t dry clothes as effectively as a standalone machine, Notion won’t perform as well in any area as dedicated, standalone tools.

If you have the space and resources to afford separate machines, it’s probably best to do so. And I urge you to consider doing the same in the digital realm. Think twice before going down the monolith route with your PKM. PKM is essentially a lifelong game, and there will likely come a point—probably multiple—when you’ll need to migrate or pivot. In such cases, you win big time using a more modular setup.

While an all-in-one solution like Notion might initially seem fast and convenient, complexity will eventually catch up with you. Remember: convenience today invites complexity tomorrow. The trade-offs of monolithic tools are real, and excellence is often found in modularity, not in the shiny allure of all-in-one solutions.

Modular Systems

Monolithic systems may appear more straightforward, cost-effective, or convenient. However, they are rarely simpler or more sustainable than systems composed of small, modular, and dedicated tools. A modular approach allows for easier repurposing, substitution, modification, combination, and extension of your system. No single tool can support everything, and as new needs arise, modular systems offer the flexibility to adapt without being constrained by the limitations of an all-in-one solution. Let’s look at five significant advantages of modular systems over monoliths.

1. Poka-Yoke for Dedication

Each tool in a modular system is designed to perform one job exceptionally well. Dedicated tools also encourage focused work. It’s much easier to open just your task manager and keep your PKC closed during stressful times—something difficult to avoid with an all-in-one tool. In contrast, tools like Notion, with their multitude of features, can become distractions rather than aids. Swiss Army knife-like tools also require you to set up additional constraints, often leading to time sinks and over-engineering. In contrast, modular tools simplify things. Modules allow you to separate concerns and maintain clarity.

2. Distributed Risk

A modular system spreads risk across multiple components, much like diversifying investments in the stock market. If one tool fails or needs to be replaced, the rest of the system remains intact. Unlike in an all-or-nothing monolithic system, you can replace specific parts without disrupting everything else.

3. Incremental Growth

With a modular system, you can grow organically and incrementally. There is no “Big Bang” required. You can build your system gradually over time. This is in line with Gall’s Law, which states that a complex system that works invariably evolved from a simple system that worked. Starting with a simple, modular system allows for natural growth and adaptation, avoiding the pitfalls of overly complex, monolithic designs. With modules, the stakes are lower. Modular systems also allow you to address specific problems as they arise, making the overall process more manageable.

4. True Customization

Modular systems allow you to build your own system. They give you true customization, enabling you to create a system that fits your unique needs and preferences. This is necessary if you want to build a system that is a perfect match for you, one that starts with your personal needs, habits, and preferences and feels like a tailored suit instead of a standardized one. True customization reduces overwhelm, increases confidence, and provides a greater sense of control.

5. Composition of Novel Use Cases

Modular systems allow for more flexible problem-solving. With small and dedicated modules, you can address specific problems with tailored solutions. As your needs change, you can “recompose” your system to match new requirements by replacing, adding, or removing some tools. With this, you avoid unnecessary bloat—you only take what you need rather than adopting a monolith with many unnecessary features.

How To Move Towards a More Modular System

Understanding the trade-offs and risks of different design approaches is invaluable when developing your systems. For instance, if you’re building a startup and need to move quickly, knowing you’ll have the resources for potential migrations later or that you won’t need to take your system with you after an exit, then a tool like Notion might make sense. However, a more modular approach is generally wiser when building a personal knowledge base for life.

So, how should you approach it if you decide to go modular?

Here are a few tips to get you started.

Start Small and Evolve Gradually

I strongly advise against a big-bang approach. A proper system should evolve organically; it’s not something you can fully design upfront. Instead, recognize where you are right now, and then incrementally, slowly, and step-by-step introduce modules into your system.

Begin By Outsourcing Task Artifact Management

One of the first steps I recommend is a dedicated approach to “task management.” Task artifact management is the heart of any productivity system, so getting this right is crucial. Start by taking stock of your current setup with a digital inventory. Then, explore various tools—My favorite for years has been Todoist. If you haven’t seen it, I have an 18-part series on building a smart task management system from first principles using Todosit as an example.

Once you’ve chosen a tool, transition to it in a safe and controlled manner. For example, start by removing task management only from your email client. Next, gradually separate tasks from your notes and other tools until all tasks are managed by your dedicated task manager.

Choose a Personal Knowledge Companion (PKC)

Next, consider getting yourself a personal knowledge companion (PKC)— a tool that is the central repository for all your knowledge. I have entries on how to choose and feed a PKC.

How To Pick A Knowledge Companion?

How To Feed A Personal Knowledge Companion?

Your PKC should be a reliable, focused tool explicitly designed for PKM rather than a catch-all solution that does everything. It is also wise to adopt a clear and simple organizing scheme such as PARA, ACEx, or my PEAKER Method.

Maintain Clear Boundaries

In a truly modular system, your apps should have dedicated jobs. Your email client, for instance, should be used for communication only—not as a task manager or reference manager. Maintaining these clear boundaries with a dedicated task manager and PKC should come naturally and easily. The same goes for all kinds of tools. Using a dedicated calendar app instead of having it integrated with your emails will be beneficial. Adopting a dedicated password manager instead of storing passwords everywhere is very helpful. As you introduce more and more boundaries, you will see how much easier your productivity will become. Even though you add more tools, you end up with less complexity as all of the tools are preferably small and simple themselves.

---

By taking these steps, you’ll gradually build a modular system that’s more sustainable, flexible, and tailored to your needs. Remember, the key is starting small, iterating, and allowing your system to grow and evolve.

Caveats and Avoiding Finicky Integrations

While modular systems offer numerous advantages, there are some caveats to remember. For example, if you’re using a tool like Obsidian, which supports plugins to add little modules of functionality, adding more plugins doesn’t necessarily make your system more modular. Strictly speaking, using a Kanban plugin within Obsidian to create a Kanban board directly in the app is a less effective approach than using a standalone tool like Trello. Relying too heavily on plugins can make your system clunky and less focused. If you install hundreds of plugins in a tool like Obsidian, you end up with something even less preferable than Notion.

Remember, you don’t need a perfect system, nor do you always need to use all the features in every one of your tools. Just focus on minimizing the use of large, complex tools that you only utilize a small portion of. These tools likely aren’t designed with your specific needs in mind.

The Integration Myth

What about integration? What if you’re not “technical” or don’t want to “waste time” connecting different tools? First, it’s important to recognize that most modular systems require little to no technical integration. You don’t need an email client that automatically pipes emails into your PKC (Personal Knowledge Companion) or task manager. You don’t need a tool that tries to do everything. I already have a paid follow-up post prepared on this specific topic soon.

Build Your Own System

This brings me to my most important point: don’t copy someone else’s system. The most significant advantage of a modular system is that you can tailor it more closely to your needs. You can build it gradually over time, allowing it to evolve as your use cases and understanding of your own knowledge grow. While it’s fine to take inspiration from others, avoid basing your system on ready-made templates that some might sell as “complete solutions.” These setups are often doomed to fail because they don’t reflect your unique workflow and preferences. Instead, focus on building your own system—one that works for you, not just in theory, but in practice.

Conclusion

Building a modular productivity system is far more effective than relying on a “tool to rule them all.” In general, it’s best to use the simplest and smallest tool that gets the job done. For most personal use cases, a tool like Notion is overkill—you simply don’t need it. However, that’s not the main reason to avoid it. Given the uncertainty of the future, it’s wise not to put all your eggs in one basket and instead aim for agility. Only a modular, gradually evolving productivity system built from composable bricks rather than on a pre-packed, knitted, unwieldy wholes can give you that. It’s time to look through the shiny “egg-laying wool-milk-pig” as it doesn’t and will never exist.

1. That is the case with Notion. It’s notoriously slow compared with other tools.