The Case for Building Your Own Tools

The Itch

Every developer hits a point where the tool they're using doesn't quite fit. Maybe it's too heavy. Maybe it's too opinionated. Maybe it just doesn't work in your context.

For me, that context is Zimbabwe. And that changes everything.

When "Just Use X" Doesn't Work

The standard advice when you need a tool is: don't build one. Use the existing solution. And most of the time, that's correct.

But sometimes it isn't. Here's when:

• The existing tool assumes reliable infrastructure. Many deployment tools assume fast, stable internet. When your connection drops mid-deploy, you need something that handles that gracefully. That's why I built SimpliCD — a deployment tool that's lightweight enough to run on a $5 VPS and resilient enough to handle spotty connections.

• The existing tool is overkill. Not every project needs Kubernetes. Not every email needs Gmail's infrastructure. Lightr exists because sometimes you just need a simple, embeddable email server that does one thing well.

• The existing tool doesn't serve your market. Try checking .co.zw domain availability programmatically. There's no API for it. So I built ZWDomain — because the tool literally didn't exist.

What Building Teaches You

Beyond solving the immediate problem, building your own tools teaches you things you can't learn any other way:

You learn the protocol, not just the API

When I built Lightr, I had to understand SMTP and IMAP at the protocol level — not just "call this function and email gets sent." I learned about SPF records, DKIM signing, mail deliverability, and why Gmail treats new servers with suspicion.

That knowledge makes me better at using email services too, not just building them.

You learn to make hard trade-offs

Every tool is a set of trade-offs. When you're the one making those decisions — what to include, what to leave out, what to optimize for — you develop an intuition for software design that's hard to get any other way.

SimpliCD deliberately has no UI. That's not laziness — it's a choice. A webhook listener that triggers a shell script is simpler to debug, simpler to secure, and simpler to understand than any dashboard.

You learn what "done" means

Open source tools need to ship. Not "ship when it's perfect" — ship when it works. I've learned to scope ruthlessly, document clearly, and resist the urge to add one more feature before releasing.

The Go Decision

Most of my tools are built in Go, and that's also a deliberate choice:

• Single binary distribution. No runtime dependencies. Download and run.
• Cross-compilation. Build for Linux, macOS, and Windows from one machine.
• Low resource usage. These tools run on cheap VPS instances where every MB of RAM counts.
• Fast startup. CLI tools should feel instant.

For tools that will be downloaded and run by others, Go's distribution story is unbeatable.

When NOT to Build

I want to be clear: I'm not advocating for building everything from scratch. I use Next.js, PostgreSQL, Prisma, and dozens of other tools I didn't build. The key is knowing the difference between:

• Infrastructure you depend on → Use proven, maintained solutions
• Tools shaped by your specific constraints → Consider building
• Tools that don't exist for your context → Definitely build

The Bigger Picture

There's something deeper here too. When you're building in Africa, you can't always wait for Silicon Valley to notice your problems. The tools we need might never be someone else's priority.

So we build them ourselves. And in doing so, we contribute back to the global open source ecosystem with perspectives and solutions that wouldn't exist otherwise.

Every .co.zw domain check through ZWDomain, every email sent through Lightr, every deploy triggered by SimpliCD — that's infrastructure being built for a context that's usually overlooked.

And that matters.

---

All the tools mentioned in this post are open source and available on my GitHub.