Werkzeuge, die tragen
nerve und fleetdeck sind keine Nebenprojekte: Auf ihnen läuft der Betrieb von Schulmittag. Warum wir tragende Infrastruktur selbst bauen — und offenlegen.
Zwei Arten von Nebenprojekten
Jeder Entwickler hat ein GitHub-Profil voller Anfänge: Experimente, Prototypen, Dinge, die ein Wochenende lang wichtig waren. Ich habe solche Repositories auch. Aber zwei meiner Projekte gehören in eine andere Kategorie, und der Unterschied ist mir wichtig: Auf ihnen läuft Produktivbetrieb. Wenn sie ausfallen, merkt es nicht mein Portfolio — es merken es Gemeinden.
fleetdeck ist unsere eigene Deployment-Infrastruktur, geschrieben in Go. Sie automatisiert Docker-Compose-Deployments mit Traefik und rollt eine neue, isolierte Schulmittag-Instanz je Einrichtung in Minuten aus. nerve ist ein Open-Source-KI-Coding-Assistent in Rust — sechs Provider, ein vollständiger Coding-Agent, eine einzige Binärdatei von 7,7 MB ohne Laufzeitabhängigkeiten. Der Betrieb von Schulmittag läuft mit beiden.
Warum selbst bauen?
Die ehrliche Antwort hat drei Teile.
Erstens: Zuschnitt. Unsere Architektur — eine isolierte Instanz je Einrichtung — ist genau die Anforderung, für die generische Plattformen Aufpreis und Komplexität verlangen. fleetdeck macht genau eine Sache: unsere Art von Deployment. Werkzeuge, die eine Sache machen, kann man verstehen. Werkzeuge, die alles machen, muss man glauben.
Zweitens: Abhängigkeit. Wer seinen Betrieb auf fremde Plattformen stellt, erbt fremde Preislisten, fremde Deprecation-Zyklen und fremde Ausfälle. Für ein Produkt, das Gemeinden als Jahreslizenz budgetieren, wollen wir Kosten und Verhalten unserer Infrastruktur selbst in der Hand haben.
Drittens, und das unterschätzt man leicht: Verstehen. Wer sein Deployment selbst geschrieben hat, debuggt anders. Es gibt keinen Support-Fall, kein „das ist bei uns eine Blackbox“. Es gibt Quellcode, und den haben wir geschrieben.
Warum offenlegen?
Beide Werkzeuge liegen öffentlich auf GitHub, obwohl sie tragende Teile unseres Betriebs sind. Das ist kein Marketing, sondern dieselbe Haltung, die auch sonst auf dieser Website steht: Wer prüfen kann, muss nicht glauben. Eine Gemeinde, die wissen will, wie ihre Instanz ausgerollt wird, kann nachlesen — nicht in einem Whitepaper, sondern im Code.
Offenheit diszipliniert außerdem den Autor. Code, von dem man weiß, dass ihn Fremde lesen können, schreibt man aufgeräumter. Das ist derselbe Mechanismus wie beim Unterrichten: Wer erklären muss, was er baut, baut klarer.
Die Grenze der Romantik
Selbst bauen ist kein Wert an sich. Wir schreiben keine eigene Datenbank, kein eigenes Betriebssystem, keinen eigenen Webserver — dort verlassen wir uns auf bewährte, langweilige Technik, und das mit Absicht. Selbst gebaut wird bei uns nur, was zwei Bedingungen erfüllt: Es ist nah an dem, was uns von anderen unterscheidet, und es ist klein genug, dass zwei Leute es über Jahre verantworten können.
Eine 7,7-MB-Binärdatei ohne Abhängigkeiten ist so ein Fall. Sie tut heute, was sie gestern tat, und sie wird es morgen tun. Das ist die ganze Anforderung an Infrastruktur: nicht glänzen. Tragen.