Why I Write My Own Tools

March 15, 2026 · 2 min read

toolsproductivityphilosophy

Every developer has a tipping point. Mine was the day I spent four hours configuring a build tool to do something I could have written in 50 lines of shell script.

I'm not against libraries. I'm against the reflex of reaching for one before understanding what you actually need.

The 50-line threshold

Here's my rule of thumb: if the core logic of what I need fits in under 50 lines, I write it myself. Not because I think I'll do it better than the open source version — but because I'll understand it better.

#!/bin/bash
# deploy.sh — the whole thing
 
set -euo pipefail
 
BRANCH=$(git branch --show-current)
if [ "$BRANCH" != "main" ]; then
  echo "Error: deploy from main only"
  exit 1
fi
 
echo "Running tests..."
npm test --silent
 
echo "Building..."
npm run build
 
echo "Deploying..."
aws s3 sync ./out s3://my-bucket --delete
aws cloudfront create-invalidation \
  --distribution-id "$CF_DIST_ID" \
  --paths "/*" > /dev/null
 
echo "Done."

That's a deploy script. It checks you're on main, runs tests, builds, and ships. No YAML. No plugins. No dependency graph of tools I don't understand.

When to reach for a library

The threshold isn't really about lines of code — it's about edge cases. I write my own tools when:

The problem is well-defined and stable
I don't need cross-platform support
The edge cases are ones I'll actually hit

I reach for a library when:

The problem involves parsing complex formats (dates, URLs, Markdown)
Security is involved (crypto, auth, sanitization)
Other people need to maintain it and conventions help

The hidden benefit

The real value isn't the tool itself. It's that building small tools keeps your fundamentals sharp. Every tiny script is a chance to practice the basics — file I/O, string manipulation, error handling — without the overhead of a full project.

The programmer who writes their own tools understands their tools. The programmer who only installs tools understands their package manager.

Build small things. Understand what they do. Ship them.