Core Primitive
Sometimes building a custom tool is worth the investment for a perfectly fitted workflow.
The spreadsheet that became an empire
In the early 1990s, a Bloomberg terminal cost roughly $20,000 per year. The financial data it provided was essential, but the analytical tools layered on top of that data were generic — designed for the median trader at the median firm. So traders at quantitative hedge funds started building their own tools. They wrote custom spreadsheets, then custom applications, then entire internal platforms that ingested Bloomberg data but processed it through proprietary models fitted precisely to their strategies. Renaissance Technologies, the most successful quantitative fund in history, did not become successful by buying the best available tools. They became successful by building tools that no one else had — tools so deeply fitted to their specific analytical approach that the tools themselves became the competitive advantage.
You are not running a hedge fund. But you are running a cognitive operation — a personal knowledge infrastructure with its own workflows, its own data flows, and its own bottlenecks. The previous lesson argued for tool minimalism: fewer, well-chosen tools outperform a sprawling collection of poorly integrated ones. This lesson asks the follow-up question that minimalism inevitably raises. What happens when the tool you need does not exist? What happens when the best available product solves seventy percent of your problem and the remaining thirty percent is where all the value lives?
The answer, sometimes, is that you build it yourself. But the word "sometimes" is doing enormous work in that sentence, and getting the sometimes right is a skill that separates practitioners who invest their time wisely from those who sink weeks into custom tools that a $10-per-month subscription would have handled better.
The economics of making versus buying
The build-versus-buy decision is not new. It is one of the foundational questions in operations management and economics, and the intellectual framework for thinking about it was laid down decades before the first personal computer.
In 1937, Ronald Coase published "The Nature of the Firm," asking a deceptively simple question: if markets are efficient, why do firms exist at all? Why don't individuals just contract with each other for every task? Coase's answer was transaction costs — the costs of searching for the right supplier, negotiating the contract, monitoring the work, and enforcing the agreement. When transaction costs are high, it is cheaper to bring the activity inside the firm. When transaction costs are low, it is cheaper to buy from the market. Oliver Williamson extended this framework in the 1970s and 1980s, earning a Nobel Prize for his work on transaction cost economics. Williamson identified three factors that push decisions toward building in-house: asset specificity (how unique the requirement is), uncertainty (how unpredictable future needs are), and frequency (how often the activity occurs). When an activity is highly specific to your context, when future requirements are hard to predict, and when you perform the activity frequently, the economics favor building over buying.
Translate this to personal tools. The activity of managing your email inbox is high-frequency but low-specificity — almost everyone has the same basic needs, which is why Gmail and Outlook serve billions of users adequately. The activity of generating your specific weekly review format, cross-referenced with your specific note taxonomy and your specific calendar structure, is high-frequency and high-specificity. No vendor optimizes for your exact intersection of systems. Williamson's framework predicts exactly what experience confirms: generic needs are best served by bought tools; specific needs at the intersection of your unique workflows are where custom builds earn their keep.
The total cost you are not counting
The naive version of the build-versus-buy calculation looks only at acquisition cost. The bought tool costs $10 per month. Building a custom tool costs twenty hours of your time. At a modest valuation of your time, the custom build costs more. Case closed — buy the tool.
But this calculation misses most of the relevant costs, in both directions.
The total cost of ownership for a bought tool includes the subscription fee, the time spent learning the tool, the time spent working around its limitations, the time spent migrating data if the tool changes its pricing or shuts down, the cognitive cost of adapting your workflow to the tool's assumptions, and the opportunity cost of the features you need but will never get because you are one user among millions and the vendor's roadmap serves the median, not you. Joel Spolsky, co-founder of Stack Overflow and one of the clearest thinkers on software development economics, wrote extensively about what he called the "strategy tax" — the cost organizations pay when they must distort their strategy to accommodate the limitations of tools they depend on but do not control. At the personal scale, the strategy tax shows up every time you change how you think about a problem because the tool cannot represent the problem the way you think about it. You reorganize your notes to fit the tool's hierarchy instead of your mental model. You skip a step in your review because the tool makes it cumbersome. You adopt a workflow you do not actually want because the tool makes it easy.
The total cost of ownership for a built tool includes the time to design and build it, the time to debug it, the time to maintain it as your needs evolve, the risk that you built the wrong thing, and the opportunity cost of what you could have done with those hours instead. Fred Brooks, in his 1986 essay "No Silver Bullet," drew a distinction between essential complexity (the inherent difficulty of the problem) and accidental complexity (the difficulty introduced by the tools and methods used to solve the problem). A custom-built tool can eliminate accidental complexity — the workarounds, the manual bridging, the format conversions — that a generic tool imposes. But building the custom tool introduces its own accidental complexity: the code you must maintain, the edge cases you did not anticipate, the brittleness of a tool built by one person without the testing and hardening that commercial products undergo.
The honest calculation accounts for all of these costs on both sides. And the answer is rarely obvious.
When the right answer is build
Certain conditions reliably favor building custom tools, and recognizing these conditions is more useful than any abstract formula.
The first condition is high frequency combined with high specificity. If you perform an activity multiple times per day and the activity requires steps unique to your workflow, even a small custom tool generates enormous cumulative returns. A shell script that reformats data between two tools you use constantly — that runs fifty times a week and saves ninety seconds each time — pays for a four-hour build investment in under five weeks. Paul Graham, in his essay on "schlep blindness," observed that people systematically undervalue solutions to tedious, recurring problems because the problems feel too boring to solve. The most valuable custom tools are often the least glamorous: a text-expansion snippet, a keyboard shortcut chain, a spreadsheet formula that eliminates a manual lookup. The boringness of the problem is precisely why no vendor has built a product for it.
The second condition is strategic differentiation. David Heinemeier Hansson, creator of Ruby on Rails and co-founder of Basecamp, has argued repeatedly that building your own tools can be a source of competitive advantage — not despite the cost, but because of it. When Basecamp built their own email service (HEY) and their own deployment platform, they were not just solving technical problems. They were ensuring that the core operations of their business ran on tools shaped by their values and their priorities, not by a vendor's roadmap. At the personal scale, the same logic applies. If your note-taking workflow is central to how you produce your best work, running it on a tool you control means that your most important cognitive process is never at the mercy of a product pivot, a pricing change, or a feature deprecation.
The third condition is when the build reveals something. Sometimes the value of building a tool is not the tool itself but the understanding you gain by building it. When you write a script to automate your weekly review, you are forced to make explicit every step that was previously implicit. You discover that your review actually has seven steps, not the four you thought. You realize that step three depends on data from a source you had been consulting unconsciously. The act of encoding your workflow in code is a form of externalization — the same process that the Zettelkasten method uses for knowledge. The tool becomes a mirror of your practice, and looking in that mirror teaches you things about your practice that you could not see from inside it.
When the right answer is buy
The conditions favoring bought tools are equally recognizable, and ignoring them leads to the most common build-versus-buy mistake: "Not Invented Here" syndrome.
When your requirements are standard — when thousands of other people need roughly the same thing — a commercial tool will almost certainly be better than what you can build alone. The tool has been tested by thousands of users, hardened against edge cases you would never think of, and maintained by a team whose full-time job is keeping it working. Clayton Christensen's research on disruptive innovation demonstrated that incumbents are displaced when they over-serve mainstream needs while ignoring emerging ones. The corollary for personal tools is that commercial products serve mainstream needs extremely well. If your needs are mainstream, fighting the current by building custom is waste disguised as craftsmanship.
When the maintenance burden is high relative to your skill and interest, buying is also the right answer. A custom tool that requires ongoing maintenance becomes a second job you did not sign up for. If you do not enjoy the maintenance, you will defer it. The tool will decay. Within six months, you will be working around the bugs in your own custom tool — which is exactly the problem you were trying to solve by building it in the first place, except now there is no vendor support and no community forum. The tool has become worse than the commercial alternative it replaced.
Eric Raymond, in "The Cathedral and the Bazaar," identified a middle path that is worth noting: open source. When no commercial tool fits your needs but building from scratch is too expensive, an open source project can serve as the foundation. You get the benefit of community maintenance and testing while retaining the ability to modify the tool for your specific requirements. Obsidian plugins, browser extensions with open source codebases, and configurable command-line tools all occupy this middle ground. You are neither fully building nor fully buying. You are customizing — and customization is often the sweet spot between the two extremes.
A decision framework you can use today
Rather than relying on intuition, apply five questions to any build-versus-buy decision.
Frequency: How often will you use this tool? Daily use justifies a larger build investment than monthly use. If you will use it fewer than fifty times, the answer is almost certainly buy (or do without).
Strategic value: Is this tool central to your most important work, or peripheral to it? Central tools are worth building because they compound. Peripheral tools are worth buying because they should not absorb your attention.
Available skill: Can you actually build what you need at an acceptable quality level? Honest assessment here prevents the most painful build failures. If the build requires skills you do not have and do not want to develop, buy.
Maintenance burden: Who will maintain this tool in six months? If the answer is "me, and I will resent it," buy. If the answer is "me, and I will enjoy improving it," build.
Opportunity cost: What will you not do during the hours you spend building? If the displaced activity is more valuable than the tool, buy. If the displaced activity is less valuable — if the build is itself the highest-value use of your time — build.
No single question is decisive. But when three or more point in the same direction, the decision is usually clear. Write the five answers down. The act of writing prevents the romanticization of building (which feels creative and autonomous) and the lazy default to buying (which feels safe and easy).
The Third Brain
AI has fundamentally changed the economics of the build side of this equation. Tasks that once required hours of coding — writing a script to parse and reformat data, building a browser extension to automate a repetitive workflow, creating a custom integration between two APIs — can now be prototyped in minutes with AI assistance. The threshold of "available skill" has dropped dramatically. You do not need to be a proficient programmer to build a small custom tool; you need to be a clear describer of what the tool should do, and AI handles the translation from description to implementation.
This changes the decision framework in a specific way: it makes small, disposable builds viable. Previously, building a custom tool was an investment that had to justify significant time. Now, you can prototype a solution in thirty minutes, use it for a week, and discard it if it does not work — with minimal sunk cost. The "try building it" option has become cheap enough to treat as an experiment rather than a commitment. But the maintenance question remains. AI can help you build a tool quickly, but maintaining that tool as your workflow evolves still requires understanding what the tool does and why. The danger is generating code you cannot read, cannot debug, and cannot adapt. Use AI to accelerate the build, but make sure you understand what was built. A tool you cannot maintain is a tool that will eventually betray you.
The bridge to documentation
The decision to build a custom tool — whether it is a shell script, a spreadsheet formula, a browser extension, or a small application — creates an immediate follow-on problem. You built the tool. It works. It fits your workflow perfectly. And then three months later, your laptop dies, or you set up a new machine, or you need to modify the tool because your workflow changed, and you cannot remember how the tool works, where the configuration lives, or why you made the design choices you made.
Building a tool without documenting it is like writing a synthesis note without linking it to anything — it exists, it contains value, but it is disconnected from the system that gives it durability. The next lesson addresses this directly: how to document your tool configurations and workflows not for other people but for your future self — the person who will need to recreate, modify, or debug what you built today.
You now know when to build and when to buy. The next step is making sure that what you build survives the context in which you built it.
Sources:
- Coase, R. H. (1937). "The Nature of the Firm." Economica, 4(16), 386-405.
- Williamson, O. E. (1985). The Economic Institutions of Capitalism: Firms, Markets, Relational Contracting. Free Press.
- Brooks, F. P. (1986). "No Silver Bullet — Essence and Accident in Software Engineering." Proceedings of the IFIP Tenth World Computing Conference.
- Raymond, E. S. (1999). The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. O'Reilly Media.
- Spolsky, J. (2002). "In-House vs. Outsource." Joel on Software.
- Graham, P. (2012). "Schlep Blindness." paulgraham.com.
- Heinemeier Hansson, D. (2020). Various writings on building tools as competitive advantage. hey.com/basecamp.com.
- Christensen, C. M. (1997). The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail. Harvard Business Review Press.
Frequently Asked Questions