What does it mean that build versus buy?

Sometimes building a custom tool is worth the investment for a perfectly fitted workflow.

Example: You use a popular project management app for your weekly review. It does eighty percent of what you need — task lists, due dates, tags. But every Sunday you spend twenty minutes manually copying completed items into a separate reflection journal, reformatting them into questions about what worked and what did not, then cross-referencing with your calendar to see how actual time allocation compared to planned allocation. You have been doing this manual bridging step for nine months. One Saturday afternoon, you write a sixty-line script that pulls completed tasks from the app's API, generates the reflection prompts automatically, and merges calendar data into a single weekly review document. The script takes four hours to build. It saves twenty minutes per week. By week thirteen, the script has paid for itself in raw time. But the real return is not the time saved — it is the fact that you now actually do the reflection every week instead of skipping it when you are tired, because the friction that made you skip it was the manual bridging, and the manual bridging is gone. You built a small tool because no product on the market serves the exact intersection of your task manager, your reflection practice, and your calendar. That intersection is yours alone. No vendor will ever optimize for it.

Try this: Conduct a build-versus-buy audit of your current workflow. Step 1: Identify three recurring friction points in your daily or weekly work — moments where you manually bridge between tools, reformat information, or perform repetitive steps that feel like they should be automated. Write each one down with a rough estimate of how many minutes per week it costs you. Step 2: For each friction point, research whether an existing tool, plugin, or integration solves it. Spend no more than fifteen minutes per friction point searching. Note what you find, including the cost and the degree of fit (does it solve 90% of the problem or 60%?). Step 3: For the friction point where the buy option fits least well, sketch what a custom-built solution would look like. You do not need to build it yet. Just describe what it would do, what inputs it would take, what outputs it would produce, and roughly how complex it would be (a spreadsheet formula, a shell script, a browser extension, a small application). Step 4: Apply the decision framework from this lesson — frequency, strategic value, available skill, maintenance burden, and opportunity cost — to decide whether the custom build is worth pursuing. Write your decision and your reasoning. If the answer is build, schedule two hours this week to prototype it.