Vier Monate eigene Arbeit weggeworfen — und warum das die richtige Entscheidung war

Drei Anläufe, zwei davon im Papierkorb

Oktober 2025 — ein Flutter-Grundgerüst. Ein Commit, dann liegen geblieben.

Februar bis März 2026 — pongPartner, 52 Commits. Eine echte App mit Match-Tracking, ersten Turnierfunktionen und einem durchdachten Konzept, wie man Ergebnisse von Spielern ohne Konto nachträglich einem echten Konto zuordnet. Weit genug, um weiterzumachen.

Juni 2026 — statt weiterzumachen: sechs Dokumente. Bestandsaufnahme, Marktrecherche, Strategieentscheidung, Anforderungen, Architektur, Fahrplan.

Was die Recherche ergab

Zwei Befunde, die die Richtung gekippt haben.

Erstens: Reine Score-Tracker haben eine belegbare Decke. Vergleichbare Apps kommen über wenige hundert Downloads nicht hinaus. Das ist kein Ausführungs-, sondern ein Kategorieproblem — die App wird einmal im Jahr auf einer Party gebraucht und danach deinstalliert.

Zweitens: Die Nutzung liegt in der Turnierorganisation. Wer ein Turnier ausrichtet, hat ein echtes, wiederkehrendes Problem: zwanzig Leute, ein Turnierbaum, ständige Rückfragen nach dem Spielstand. Der Score-Tracker ist die Schicht, die Leute zurückholt — aber kein Produkt für sich.

Daraus wurde die Produktthese, die alles Weitere bestimmt hat:

„Das Turnier verwaltet sich selbst, und niemand muss etwas installieren.“

Warum die These die App ausschloss

Der Kern ist der geteilte Link. Ein Teilnehmer bekommt eine Nachricht, tippt darauf und ist im Turnier — kein Store, kein Download, kein Konto. Ein Zuschauer öffnet dieselbe Adresse auf dem Fernseher im Raum.

Das ist im Web selbstverständlich und in einer App ein Widerspruch. Jeder Weg, das mit einer installierten App zu bauen, führt über eine Hürde, die genau die Leute abschreckt, die man erreichen will.

Damit war die Entscheidung keine Geschmacksfrage mehr. Die Entscheidungsvorlage listet die Kosten ausdrücklich mit auf — sinngemäß: rund 90 Dateien Flutter-Code werden verworfen, aber die Oberfläche hätte ohnehin neu gemusst, Tests gab es keine, und die Turnierlogik musste ohnehin neu geschrieben werden.

Das ist der Satz, auf den es ankommt. Nicht „der alte Code war schlecht“, sondern eine nüchterne Aufstellung dessen, was verloren geht — und die Feststellung, dass der größere Teil ohnehin angefallen wäre.

Was aus dem Vorgänger überlebt hat

Nicht der Code, aber das Denken: das Datenmodell, das Regelwerk für Spielabläufe und vor allem das Verfahren, mit dem sich nachträglich ein Spielerkonto mit bereits gespielten Partien zusammenführen lässt. Das war in pongPartner fertig durchdacht und ist unverändert übernommen worden.

Vier Monate Arbeit sind also nicht verschwunden. Verschwunden ist die Implementierung — der Teil, der am schnellsten wieder entsteht, wenn das Konzept steht.

Wie der Neubau gebaut ist

Die Turnierlogik liegt in einem eigenen Paket ohne Laufzeitabhängigkeiten. Sie ist die einzige Stelle, an der ein Fehler ein laufendes Turnier zerstört — entsprechend vollständig ist sie getestet, ohne Datenbank, ohne Browser, mit in der Konfiguration erzwungenen Abdeckungsschwellen.

Der Datenbankzugriff ist standardmäßig verboten und wird pro Tabelle gezielt freigegeben. Schreibvorgänge, die mehrere Regeln gleichzeitig berühren, laufen über Funktionen mit festgelegten Rechten statt über direkten Tabellenzugriff.

Die Anwendung läuft in Docker auf einem eigenen Server hinter Caddy mit automatischem TLS, ausgeliefert über GitHub Actions. Deutsch und Englisch sind von Anfang an gleichwertig — nicht nachgerüstet.

Warum das hier steht

Diese Case Study hat die schwächsten Nutzerzahlen von allen auf dieser Seite und ist trotzdem die, auf die ich am meisten Wert lege.

Auftraggeber kaufen selten ein fertiges Feature. Sie kaufen jemanden, der merkt, wenn der eingeschlagene Weg nicht zum Ziel führt, und der es sagt, bevor das Geld ausgegeben ist. Diese Entscheidung habe ich gegen meine eigene Arbeit getroffen und dokumentiert. Gegen einen fremden Plan fällt sie leichter.