The case for building your own tools

Update, September 2026: I've since rewritten Lightr and SimpliCD, and neither is in Go any more. Why I rewrote two of my Go tools picks up where this post leaves off.

Every developer eventually hits a tool that doesn't quite fit. It's too heavy, or too opinionated, or it just doesn't work where you are.

For me, "where you are" is Zimbabwe, and that changes more than you'd expect.

When "just use X" doesn't work

The standard advice is not to build your own tool: use the existing one. Most of the time that's right. But I keep running into three cases where it isn't.

The first is when a tool assumes reliable infrastructure. A lot of deployment tooling assumes a fast, stable connection, and when yours drops halfway through a deploy you need something that copes with it. That's why I built SimpliCD: light enough to run on a $5 VPS, and sturdy enough to handle a spotty connection.

The second is when the tool is overkill. Not every project needs Kubernetes, and not every email needs Gmail's infrastructure behind it. Lightr exists because sometimes you just want a small email server you can embed, that does one thing well.

The third is when the tool doesn't serve your market at all. Try checking whether a .co.zw domain is available from code. There's no API for it. So I built ZWDomain, because the tool didn't exist.

What building teaches you

Solving the immediate problem is only half of it. Building your own tools teaches you things that using other people's doesn't.

You learn the protocol, not just the API. Building Lightr meant understanding SMTP and IMAP at the protocol level, not "call this function and an email gets sent". I learned about SPF records, DKIM signing, deliverability, and why Gmail is suspicious of new servers. That makes me better at using email services too, not only at building them.

You learn to make trade-offs. Every tool is a stack of decisions about what to include, what to leave out and what to optimise for, and making them yourself builds a feel for design that's hard to get any other way. SimpliCD deliberately has no UI. That isn't laziness, it's a choice: a webhook listener that runs a shell script is easier to debug, easier to secure and easier to understand than any dashboard.

And you learn what "done" means. Open source tools have to ship, and "ship when it works" beats "ship when it's perfect". I've learned to cut scope hard, document clearly, and resist adding one more feature before a release.

Why Go

Most of my tools are written in Go, and that's deliberate too. It compiles to a single binary with no runtime to install: download it and run it. I can build for Linux, macOS and Windows from one machine. It's frugal with memory, which matters on cheap VPSs where every megabyte counts. And it starts instantly, which is what a CLI should feel like.

For tools other people will download and run, Go's distribution story is unbeatable.

When not to build

To be clear, I'm not arguing for building everything from scratch. This site runs on Next.js, PostgreSQL and Prisma, and on dozens of other things I didn't write. The line I try to draw is simple. Infrastructure you depend on should be proven and maintained by someone else. Tools shaped by your particular constraints are worth considering building. And tools that don't exist for your context at all, you should just build.

The bigger picture

There's one more reason. When you're building in Africa, you can't always wait for someone elsewhere to notice your problems, because they may never be anyone else's priority. So we build the tools ourselves, and in doing that we put things into open source that wouldn't exist otherwise.

Every .co.zw check through ZWDomain, every email through Lightr and every deploy through SimpliCD is a small piece of infrastructure built for a context that usually gets overlooked.

Lightr and ZWDomain are open source, on my GitHub. SimpliCD's source is private these days, because it deploys my own servers.