Tools that hold up

Two kinds of side projects

Every developer has a GitHub profile full of beginnings: experiments, prototypes and weekend interests. So do I. Two projects are closely tied to my daily work: nerve supports development, fleetdeck deployment. Their roles differ. A coding assistant is not a school’s running service; a deployment tool is not the application itself.

fleetdeck is our deployment infrastructure written in Go. It automates Docker Compose and Traefik deployment steps and supports separate Schulmittag instances. Actual setup time also depends on configuration, data and coordination. nerve is my AI coding assistant in Rust. Its source is currently private, a change from the original publication status of this article.

Why build it yourself?

The honest answer has three parts.

First, fit. Our isolated-instance-per-institution architecture is exactly where generic platforms add cost and complexity. fleetdeck does one thing: our kind of deployment. A single-purpose tool can be understood; an all-purpose tool demands belief.

Second, dependency. Relying on outside platforms means inheriting their pricing, deprecation cycles and outages. For products municipalities budget annually, we want control over infrastructure cost and behaviour.

Third, understanding. Writing your own deployment changes debugging. There is no support case or black box: there is source code, and we wrote it.

Why make it open?

fleetdeck is public on GitHub, making its implementation inspectable. nerve currently lacks that public inspectability. A municipality can read how its instance is deployed in the code, not a white paper.

Openness also disciplines the author. Code that others may read tends to be written more clearly. It is the same mechanism as teaching: explaining what you build helps you build clearly.

The limit of romanticism

Building in-house is not an end in itself. We do not write our own database, OS or web server; there we deliberately use proven, ordinary technology. We build only what is close to our distinguishing work and small enough for two people to maintain responsibly for years.

Small tools also need maintenance. New requirements, bugs and interface changes do not disappear inside a compact binary. What matters is whether I can keep providing the necessary care.

Further reading: nerve in the project directory and fleetdeck with public source code.