Don't be afraid to build a tool. Just don't become too attached to it.
When managing infrastructure or building and testing software, you'll inevitably find repetitive tasks that feel like a tool should exist to make them easier or faster.
Maybe one exists, perhaps it doesn't. Either way, your team doesn’t know.
So inevitably, the tasks stay manual, inefficient, and frustrating.
Everyone wishes there was a tool—so why not build one?
😱 Why People are Afraid to Build Tools:
1️⃣ “What if something already exists?”
You build something, then someone says, “Why didn't you just use X?”
That moment sucks, especially if you didn't know X even existed.
Don't defend it, own it, and say: “I didn't know X existed, let me take a look at it.”
No one expects you to know every tool out there.
Building something and later discovering a better tool is not a failure.
It's a learning experience; what you learn while building the tool is priceless.
2️⃣ “I don't want to maintain another system.”
This is a genuine concern.
But maintaining a small set of tools that save hours of repetitive work or enable something that couldn't be done otherwise is often worth it.
The key is to reduce overhead early on:
-
Prefer CLI tools vs services
-
Minimize dependencies
The less complexity, the easier it is to manage.
3️⃣ “We are too busy building features.”
This one is hard, not because it's a technical challenge. But because it's a mindset change.
Teams get so focused on what they’re building that they forget to look at how they are building it.
If a process is slow, manual, or error-prone, that's a signal that it could be improved.
The secret is taking a step back and re-evaluating how.
👨🔬 How I Approach Building Tools:
1️⃣ Look for existing tools
I prefer open source, so that's where I start. There is a lot out there, and you have to search for it.
2️⃣ Look for “close enough” projects
You might not find a project that does exactly what you want. But maybe it's 80-90% of the way there.
If it's close, extend it, contribute upstream. Or fork it (license permitting).
3️⃣ If nothing fits, build new
If nothing meets your needs, then build it.
Start small, use it yourself, share it with your team and solicit feedback.
😍 Don't Become Too Attached:
When someone says, “Why not use X?” Evaluate X objectively.
Is it the best tool now? If so, use it.
Using a well-known, widely adopted tool is often more efficient.
🧠 Final Thoughts:
Custom tools can be lifesavers.
They only become a problem when someone gets too attached and refuses to replace them with more standard solutions.
Build tools when needed, replace them when something better appears.
A Kenjutsu Instructor (Japanese Swordsmanship) I knew would always warn us. He’d say Americans always want to treat the sword like it’s a precious gem. It's a tool; treat it like you would a hammer.
I think that applies here as well.