Eine Belegkette in einem Satz, ein Sprint durch neun Phasen

Zwei völlig unterschiedliche Projekte, aber derselbe Rhythmus: kurze, konzentrierte Sprints, die in wenigen Sessions weit über das ursprünglich Geplante hinauswachsen. Ein Nachmittags-Prototyp wurde zu einer Nextcloud-App mit kompletter Belegkette, ein abgeschlossener Reboot zu neun durchgezogenen Roadmap-Phasen.

Nextcloud-ERP: Vom Nachmittags-Prototyp zur kompletten Belegkette

Was als Antwort auf eine einzelne Frage begann — “gibt es für Nextcloud eigentlich ERP-Erweiterungen?” — ist in den letzten Wochen zu einem ernstzunehmenden Open-Source-Add-on gewachsen: Termine über die echte Kalender-App, Kunden über die echten Kontakte, Dateien im echten Nextcloud-Dateisystem, nur die eigentliche Geschäftslogik (Projekte, Artikel, Preise, Rechnungen) neu gebaut, statt alles ein zweites Mal zu speichern.

In einer einzigen durchgehenden Session entstanden vier Roadmap-Phasen auf einmal: das Fundament (Docker-Testumgebung, zehn Architekturentscheidungen), ein eigenes fünfstufiges Rechtemodell, die direkte Nextcloud-Integration (Kontakte, Kalender, Dateien ohne Datenduplizierung) und ein erster Projektkern mit automatisch generierter Projektnummer und automatisch angelegtem Projektordner. Direkt im Anschluss kamen Artikel, Angebote, Zeiterfassung, Rechnungen, Lagerverwaltung mit Inventur, ein Fuhrpark-Modul und eine Kosten-/Kalkulationsrechnung dazu — Phase um Phase, jede mit eigenem Feature-Branch, eigenen Tests und einem Merge erst nach bestandenem Durchklicktest.

Der größte Sprung kam aus einem einzelnen Satz Nutzerfeedback: Aufträge sollten sich in Lieferscheine und Rechnungen verwandeln lassen, dazu Teilrechnungen und eine Schlussrechnung mit Übersicht über bereits gestellte Teilbeträge. Aus drei kurzen Sätzen wurde eine vollständige, vierstufige Belegkette (Angebot → Auftrag → Lieferschein/Rechnung) mit einer bewussten Grenze: Die Schlussrechnung zeigt frühere Teilrechnungen nur informativ an, rechnet sie aber nicht automatisch gegen — korrekte Abschlagsrechnungs-Arithmetik nach deutschem Steuerrecht ist rechtlich nicht trivial genug, um sie einfach mitzubauen.

Die letzten beiden Ausbaustufen brachten ein echtes Dashboard mit Projekt-Gewinn/Verlust-Rechnung über fast alle Module hinweg, dazu einen CSV-Export und die Möglichkeit, Termine und Aufträge anderen Mitarbeitenden zuzuweisen, inklusive Kollisionserkennung im Kalender. Über den gesamten Zeitraum: durchgehend Feature-Branches, PHPUnit-Tests bei jeder Phase (inzwischen 266 grüne Tests), und die komplette Kette wurde mehrfach nicht nur per API, sondern tatsächlich durchgeklickt. Repo: github.com/KayBeckmann/Nextcloud-ERP (MIT-Lizenz).

Void-Trader: Ein Sprint durch neun Roadmap-Phasen

Nach einem Reboot des Weltmodells legte Void-Trader — ein Flutter/Flame-Weltraumhandelsspiel — einen bemerkenswerten Lauf hin: neun Roadmap-Phasen in wenigen Tagen. Den Anfang machte ein seed-basiertes Chunk-Weltmodell mit sechs vertikalen Ebenen und einer deterministischen Wasserphysik — Wasserzellen, die anteilig zu niedrigeren Nachbarzellen fließen, ohne dass dabei jemals Gesamtmenge verloren geht. Bewusst komplett headless testbar, ganz ohne Rendering, damit “Wasser fließt korrekt” eine reine Unit-Test-Frage bleibt statt einer visuellen Vermutung.

Darauf folgten Schlag auf Schlag: prozedurale Weltgenerierung, eine Oberflächen- und Physikengine, eine Produktionslinie, ein NPC-Grundsystem, ein Wirtschafts-/Marktmodell und der Start einer Orbit-Brücke zwischen Planetenoberfläche und Weltraum — dazu eine eigene Pixel-Art-Pipeline, Bewegung/Kollision/Fog-of-War, ein HUD v2 mit Minimap, eine erste UI-Slice samt eines gefundenen Determinismus-Bugs, eine Minendrohnen-Logik und zuletzt das Abdichten einer Pumpe für den MVP sowie eine erste Systemkarte. Repo: github.com/KayBeckmann/Void-Trader.

Fazit

Beide Geschichten zeigen dasselbe Muster von der anderen Seite: Nextcloud-ERP wuchs von außen, getrieben durch Nutzerfeedback, das sich beim genaueren Hinsehen immer als größer entpuppte, als der erste Satz vermuten ließ. Void-Trader wuchs von innen, getrieben durch eine Roadmap, die sich Phase für Phase konsequent abarbeiten ließ, weil das Fundament (deterministische, headless testbare Simulation) von Anfang an stimmte. Unterschiedliche Ausgangspunkte, dasselbe Ergebnis: Wenn die Basis trägt, lässt sich in kurzer Zeit erstaunlich viel draufbauen.