Making-of

Schneespur

Ein Fünf-Minuten-Gespräch. Dann ist es eskaliert.

Das Problem

Rutscht jemand auf einem nicht geräumten Gehweg aus, haftet der Betreiber — es sei denn, er kann nachweisen, dass doch geräumt und gestreut wurde, zu dieser Zeit, an dieser Adresse. Ein Zettel hält da selten stand. Und die Software, die es gibt, ist entweder ein teures Monatsabo, sieht aus wie 2009 oder ist für Konzerne gebaut — nicht für jemanden, der nebenbei Winterdienst macht, um ein paar Euro dazuzuverdienen.

Wer es hatte

Mein Kollege Julian. Wir haben in der Arbeit kurz übers Vibe Coding geredet; ich: „Brauchst du was?“, er: „Klar.“ Er macht im Winter Winterdienst — Schnee schaufeln, Wege freiräumen — und in Deutschland dokumentiert man das besser. Das war das ganze Briefing. Fünf Minuten.

„Also habe ich gesagt… klar, kann ich dir machen. Klingt nach einem interessanten Projekt / Nutzungsfall — und paar Stunden später ist das Ganze schon eskaliert. Wie man es von mir auch kennt.“ — aus dem Blogartikel, wie Schneespur entstanden ist

Wie es gebaut wurde

Hier hat das Hobby einen Gang hochgeschaltet. Bis dahin waren es n8n-Workflows und WordPress-Plugins. Schneespur brauchte eine richtige Anwendung — Laravel mit PostgreSQL, GPS-Tracks, Wetter-Snapshots zu Beginn und Ende jedes Einsatzes, bis zu fünf Fotos, ein PDF-Einsatznachweis, der in dem Moment entsteht, in dem der Fahrer auf „Job beenden“ tippt, eine Fahrer-PWA, die im Führerhaus auch offline funktioniert, ein Kundenportal. Ich bin kein gelernter Programmierer; allein hätte das Jahre gedauert oder wäre nie passiert.

Also habe ich es so gebaut, wie es unter ./how steht: Claude Code als Agent, GSD als Disziplin — jedes Feature besprochen und geplant, bevor Code entsteht, in kleinen Plänen umgesetzt, von mir auf einer echten Installation geprüft. Entscheidungen, die ich wieder so treffen würde: Die Fahrer nutzen die OwnTracks-App statt einer eigenen (kein App Store, nichts zu pflegen). Es läuft auf einem normalen Webhosting-Paket, weil ein kleiner Betrieb genau das schon hat. Und der Kern bleibt bewusst klein — GPS, Wetter, Fotos, PDF. Alles andere (Lager, Verträge, Telegram, Touren) ist ein Modul, das man weglassen kann. So kann eine Codebasis auch in Deutschland Schneespur heißen und überall sonst Wintertrace — Name und Rechtliches wechseln mit der Sprache.

Und dann die Frage, die niemand einem Hobbyprojekt stellt, aber jeder stellen sollte: Wer prüft eigentlich den Code der KI? Meine Antwort waren zwei Penetrationstests — gefahren von einem anderen KI-Agenten (Strix, absichtlich auf einem Modell einer anderen Familie), einmal Whitebox gegen den Quellcode, einmal Blackbox gegen eine laufende Wegwerf-Demo. Sieben Befunde, zwei davon ernst, alle in der nächsten Version behoben, jeder mit einem eigenen Regressionstest. Der komplette Bericht ist öffentlich im Schneespur-Blog. Lieber das veröffentlichen als so tun, als ob.

• von „brauchst du was?“ zur laufenden App: ein paar Wochen, Frühjahr 2026
• läuft als Schneespur (DE), Wintertrace (international) und schneespur.cz — eine Codebasis
• Installer ist eine Datei: hochladen, im Browser öffnen, nach ~10 Minuten fertig
• signierte (Ed25519) Ein-Klick-Updates über Jenni
• 2 KI-Penetrationstests · 7 Befunde · alle behoben, jeder mit Regressionstest
• 48-Stunden-Wegwerf-Demos, die jeder anfordern kann

Was heute läuft

Echte Betriebe, echte Winter. Ein modularer Kern mit wachsendem Modulverzeichnis, ein Kundenportal, und der Pentest gehört inzwischen zu jedem Release. Außerdem hat es die nächsten Projekte aus dem Boden gezogen — die Updates brauchten Jenni, die Verträge brauchten NoSign.

Jenni

In Forrest Gump ist Jenny der Grund, warum Forrest läuft. Jenni ist der Grund, warum meine Updates verifiziert sind.

Das Problem

Schneespur ist Open Source: keine Registrierung, kein Nach-Hause-Telefonieren, herunterladen und es gehört dir. Wie bekommt also ein Betrieb, von dem ich nie gehört habe, die nächste Version? Jede Installation da draußen braucht Updates. Jedes WordPress-Plugin braucht einen stabilen Update-Endpunkt, eine prüfbare Prüfsumme, einen Virenscan, auf den jemand zeigen kann. Ich habe Downloads schon vorher selbst gehostet — schlecht: Build zippen, in einen Ordner werfen, verlinken. GitHub ist der Ort, an dem ich Code zeige, nicht der, von dem Produktivsysteme ihre nächste Version holen sollten.

Wer es hatte

Ich. Nur ich. Das unglamouröseste Projekt auf dieser Seite und das, das ich am meisten benutze.

Wie es gebaut wurde

„Ich habe Claude gebeten, mir einen Download-Server zu bauen.“ Bei dem Satz zucken Entwickler zusammen — sie stellen sich ungeprüften KI-Output vor, der in die Produktion kopiert wird. Jenni war das Gegenteil: das Projekt, mit dem ich mir selbst die verantwortungsvolle Version davon beweisen wollte. Weil es Infrastruktur ist. Sie läuft auf den Systemen anderer Leute und liefert Dateien an Dritte aus.

Also war der Bau langsam, wo es darauf ankam. Jedes Problem kam einzeln und bekam seine eigene GSD-Phase: erst schlichte versionierte Downloads und eine Update-API. Dann ein JSON-Katalog, weil Schneespur ein Modulverzeichnis wollte, ohne dass ich einen Marktplatz betreibe. Dann das unangenehme: Mein Auto-Updater hat für alles TLS vertraut — ein gekaperter Server hätte bis zum Morgen jedem Client alles unterschieben können. Also hat Jenni gelernt, jedes Release mit Ed25519 zu signieren, mit einem Root-Schlüssel, der auf meinem Laptop liegt und nie auf dem Server. Dann eine Autoren-API, damit Modul-Entwickler ihre eigenen Uploads durch dieselbe Scan-und-Signier-Pipeline schicken können.

Ich habe jede Zeile der Upload-Pipeline gelesen. Magic-Byte-Prüfung, Zip-Slip-Schutz, Zip-Bomb-Limits, ClamAV bei jedem Upload, Argon2id, Login mit Rate-Limit, TOTP-2FA, Container ohne Root. Dann lief sie monatelang gegen meine eigene Produktion, bevor sie eine Website bekam. Der Code ist schnell. Das Vertrauen ist langsam.

• ein Binary: Downloads · Update-API · Ed25519-Vertrauensschicht · wp.org-Deploy · Modulkatalog · Autoren-API
• Root-Signierschlüssel offline — ein gekaperter Server kann lügen, aber nicht fälschen
• liefert jedes BreznFlow-Release und jedes Schneespur-Update aus · null Vorfälle
• die Download-Widgets unter ./projects kommen live von ihr

Was heute läuft

jenni.noschmarrn.dev — meine „Staging, aber eigentlich Produktion“-Instanz. Das meistgenutzte und am wenigsten besprochene Stück in meinem Stack. Ein öffentliches Repo und ein Setup-Assistent fehlen noch, bevor sie öffentlich wird.

NoSign

«No Schmarrn. Just Signatures.»

Das Problem

Schneespur bekam ein Modul, mit dem Betreiber Verträge für ihre Kunden direkt in der App erstellen — Kunde und Objekt wählen, Vorlage nehmen oder selbst schreiben, fertig. Was fehlte, war die Unterschrift. Der übliche Tanz — ausdrucken, per Post oder Treffen, unterschreiben, zurückschicken, scannen, ablegen — ist langsam und freudlos. Kunden sollen einfach unterschreiben. In Sekunden. Am Handy.

Wer es hatte

Die Schneespur-Betriebe — und, wie sich herausstellte, jeder, der je nach einem Open-Source-Tool für E-Signaturen gesucht hat. Ich habe die vorhandenen ausprobiert; die sind gut. Aber je nach Tool gab es die Funktion, die ich brauchte, entweder nicht oder nur im Abo: Eines hatte alles, aber die API war ein kostenpflichtiges Extra bei einer App, die sich Open Source nennt. Ein anderes war solide, hatte aber kein echtes Hard Delete — und ich will die Verträge anderer Leute nicht horten.

Wie es gebaut wurde

Statt mich an einem vierten Tool zu verbrennen, habe ich das gebaut, das ich wollte. Geplant war es nie — es sollte ein kleiner Signier-Helfer in einem Schneespur-Modul sein und ist innerhalb von Wochen zum eigenen Projekt eskaliert. Die Entscheidung über den Umfang kam zuerst und war die wichtigste: NoSign ist ein Signier-Motor, kein Tresor. Dein Backend schickt ein PDF und eine Unterzeichnerliste; NoSign führt die Zeremonie durch (E-Mail-Verifizierung, PDF ansehen, Einwilligung im Wortlaut gespeichert, zeichnen, absenden), versiegelt das Ergebnis als PAdES-B-T mit RFC-3161-Zeitstempel aus einer eigenen TSA, liefert es per HMAC-signiertem Webhook aus — und nach deiner Bestätigung löscht es alles endgültig. Übrig bleibt nur ein von personenbezogenen Daten bereinigter Grabstein. Was es bewusst nicht ist: eine qualifizierte Signatur. Kein Video-Ident, keine NFC-Ausweisprüfung. Eine einfache elektronische Unterschrift mit starkem Prüfpfad — genau das, was ein Winterdienst-Vertrag braucht.

Hier zeigt sich, was der Agenten-Workflow gut kann: Die Standards sind dicht (PAdES, RFC 3161, CMS-Signaturen), und ein Agent, der Spezifikationen liest, die Implementierung schreibt und sie gegen echte PDF-Validatoren testet, ist eine gewaltige Abkürzung. Was er nicht kann: entscheiden, was das Produkt ist. Das ist die „Motor, kein Tresor“-Entscheidung, die „jede Funktion ist kostenlos“-Entscheidung, die „Löschen nach Zustellung“-Entscheidung — alle meine, alle aufgeschrieben, bevor Code entstand.

• begann als Vertragsmodul in Schneespur — wurde zum eigenen Projekt
• mehrere Unterzeichner nacheinander · fünf Feldtypen · wiederverwendbare Vorlagen · Ablehnen & Ablauf mit Erinnerungen
• vollständige REST-API und Hard Delete sind kostenlos — keine Bezahlstufe
• öffentliche Offline-Prüfung des versiegelten PDFs

Was heute läuft

Das Vertragsmodul für Schneespur/Wintertrace ist seit Juni 2026 online und unterschreibt über meine gehostete Instanz nosign.app; das eigenständige Open-Source-Projekt lebt auf nosign.dev, für alle mit demselben Bedürfnis.

Donau2Space

Wo das alles angefangen hat. Ein TikTok-Video über n8n.

Das Problem

Ehrlich gesagt: keins. Nur eine Frage: Kann man einen Blog mit n8n komplett automatisieren — und wie weit geht das? Aus der Frage wurde Mika Stern, ein fiktiver 18-jähriger Bastler aus Passau, der an der Donau ein Amateur-Raketenprojekt baut und jeden Tag darüber bloggt.

Wer es hatte

Ich, auf dem Sofa, nach einem TikTok-Video. „Nur mal kurz damit rumspielen.“ Berühmte letzte Worte.

Wie es gebaut wurde

Das hier ist älter als Claude Code in meinem Workflow — es ist die n8n-Ära. 78 Workflows, von Hand entworfen, einer nach dem anderen: tägliche Artikel, generierte Bilder, Podcast-Vertonung über ElevenLabs, Forenbeiträge, Newsletter, Social Media. Worauf ich am stolzesten bin, ist das Gedächtnis: Mika hat ein MySQL-Langzeitgedächtnis (89 Tabellen), sodass jeder Tag eine Fortsetzung des letzten ist, und Leserkommentare fließen zurück in das, was er als Nächstes schreibt. Leser können die Geschichte anstoßen. Und jeder KI-Auftrag landet auf einer öffentlichen „KI-Blackbox“-Seite, weil ich die Maschine lieber zeige als verstecke.

Hier habe ich auch die zwei Regeln gelernt, an die sich seitdem alles hält. Erstens: Die KI hat die Ideen nicht — sie setzt sie um. Die Workflows haben sich nicht selbst geschrieben. Zweitens, auf die teure Art gelernt: Behalte deine Automatisierungen im Blick. Im Frühjahr 2026 lief ein Workflow mit kaputten YouTube-Zugangsdaten nie zu Ende und hat alle paar Minuten leise wieder bei OpenAI angefragt — über einen Monat lang. Die Blackbox-Seite hatte es die ganze Zeit angezeigt; ich hatte nur nicht hingeschaut. Voll und ganz meine Schuld, und genau so habe ich es auch aufgeschrieben. Monitoring und automatische Stopps für fehlgeschlagene Workflows sind seitdem in allem Pflicht.

Nebenwirkungen: Ich habe ständig WordPress-Plugins gebraucht, die es so nicht gab, wie ich sie wollte — daher kommen BreznGEO (SEO/GEO mit KI-Meta-Beschreibungen, llms.txt, Schema.org) und BreznFlow (interaktive n8n-Diagramme in Beiträgen). Beide kostenlos auf WordPress.org.

• 78 n8n-Workflows · ~99 % automatisiert, von Anfang bis Ende
• 252 Artikel · 252 Podcast-Folgen · ≈ 1,21 € pro Artikel, alles inklusive
• MySQL-Langzeitgedächtnis · Leserkommentare fließen in die Geschichte zurück
• hat zwei WordPress-Plugins und drei Geschwister-Charakterblogs hervorgebracht

Was heute läuft

Pausiert und wird neu gebaut — die Engine bekommt die Agenten-Behandlung. Die Knowledge Base bleibt online, als Making-of des Making-ofs.

Rastplatz.app

Das, was ich mir am Ende jeder Schicht gewünscht hätte.

Das Problem

In Deutschland — eigentlich in ganz Europa — fehlen zehntausende LKW-Stellplätze. Jeder Fahrer kennt das Gefühl: Die Lenkzeit läuft ab, die nächsten drei Rastplätze sind voll, und die Wahl ist zwischen Bußgeld und Straßengraben. Für manche Rastanlagen gibt es offizielle Belegungsdaten, aber die liegen dort, wo um 21 Uhr kein Fahrer hinschaut. Den Mangel löse ich nicht. Aber ich kann drunter greifen.

Wer es hatte

Ich, 8+ Stunden am Tag, und jeder Kollege, mit dem ich je geredet habe. Das ist das Projekt mit den meisten „wär doch schön, wenn“ dahinter — über Jahre im Führerhaus gesammelt.

Wie es gebaut wurde

Der erste Gedanke war nur „eine Karte, die zeigt, wo ich vielleicht noch einen Platz finde“. Dann ist es — wie bei Schneespur — eskaliert. Die Regel für dieses Projekt: Was ohne externe Dienste geht, wird auch ohne gemacht. Kein Google Maps. Rastplatz.app liefert seine eigene OpenStreetMap-Karte aus: Ein eigener Build-Server zieht jede Nacht die frischen Rohdaten, prüft, ob sich etwas geändert hat, und baut die Kacheln — plus einen Truck-Layer mit Höhen-, Gewichts- und Längenbeschränkungen und ADR-Einschränkungen (Gefahrgut) auf Autobahnen und in Tunneln. Eine Karte, die ein Fahrer auch ohne den Parkplatz-Teil gebrauchen kann.

Jeder Rastplatz bekommt ein Luftbild — automatisch, aus den öffentlichen Luftbildern des jeweiligen Bundeslands, mit einem kleinen Algorithmus, der aus Autobahnzufahrt, Servicestation und Anzahl der Stellplätze den richtigen Zoom bestimmt. Das Wetter kommt von einer selbst gehosteten BrightSky-Instanz (Daten des Deutschen Wetterdienstes) mit 48-Stunden-Vorhersage pro Platz. Und unter all dem: Live-Meldungen von Fahrern — „alles voll“, „noch drei frei“ — weil die offizielle Stellplatzzahl und das, was Fahrer tatsächlich tun, zwei verschiedene Dinge sind. Als Nächstes: Routing über einen eigenen Valhalla-Server. Keine Navigation — eher „Ich bin in Passau, es ist 16 Uhr, ich kann noch vier Stunden fahren und muss nach Berlin: Wo krieg ich einen Parkplatz?“

Derselbe Workflow wie bei allem hier. Claude Code baut die Pipelines; die Recherche, das „brauchen wir das?“ und die Server-Planung sind meine — inzwischen sind es sechs Server, und ich weigere mich, bei zehn zu landen. Es läuft zuerst in meinem eigenen LKW.

• eigene OpenStreetMap-Kacheln, jede Nacht neu gebaut · Truck- & ADR-Overlays
• automatische Luftbilder pro Rastplatz aus öffentlichen Landesdaten
• offizielle Belegungsdaten + Live-Meldungen von Fahrern · geheime Plätze, standardmäßig privat
• kostenlos · werbefrei · keine externen Karten- oder Wetter-APIs · DE + EN
• zukünftiges Flaggschiff — fertig ist, wenn’s fertig ist

Was heute läuft

Eine frühe Version auf rastplatz.app: die Karte, die Rastplatz-Seiten, die Luftbilder. Noch kein richtiges Design — erst die Leitungen, dann die Farbe. In aktiver Entwicklung.