LiveSL-02
Vier Monate eigene Arbeit weggeworfen — und warum das die richtige Entscheidung war
Rackd ist eine Turnierplattform, bei der niemand etwas installieren muss. Davor lagen zwei Anläufe als App, die ich beide verworfen habe. Am 11.06.2026 habe ich schriftlich begründet, warum ich vier Monate eigene Arbeit aufgebe und neu anfange. Dieser Bericht handelt von der Entscheidung, nicht vom Ergebnis.
Projekt ansehen
SL-02Live
Rackd
17 · Teams im ersten gespielten Turnier
37 · Spieler in diesem Turnier
Belegte Zahlen
- Teams im ersten gespielten Turnier
- 17Quelle: Datenbank der laufenden Plattform, Turnier gespielt am 07.07.2026, Stand 07.09.2026
- Spieler in diesem Turnier
- 37Quelle: Datenbank der laufenden Plattform, Stand 07.09.2026
- Ausgespielte Partien
- 35Quelle: Datenbank der laufenden Plattform, Stand 07.09.2026
- Handgriffe im bisherigen Ablauf
- 5Quelle: Ankündigung, Anmeldung, Warteliste, Auslosung und Tabelle — Ablauf bei Turnieren, an denen Julian teilgenommen hat
- Verworfene Dateien der alten App
- ~90Quelle: docs/03-strategy-decision.md, 11.06.2026
- Einzelne Änderungen im verworfenen Vorgänger
- 52Quelle: git log pongPartner, 14.02.2026 bis 16.03.2026
Ausgangslage
Beerpong-Turniere werden bis heute auf Papier oder in Tabellen geplant. Ich hatte dafür schon zwei Anläufe als App gemacht. Der erste blieb ein Gerüst. Der zweite war deutlich weiter: Er zählte Spiele mit und hatte erste Turnierfunktionen. Auch ein Verfahren war fertig durchdacht, mit dem ein Spieler später ein Konto anlegen und seine alten Spiele behalten kann.
Ergebnis
Eine laufende Plattform. Turniere werden über einen geteilten Link gespielt, ohne Installation und ohne Konto für die Teilnehmer. Der erste Ernstfall war am 7. Juli 2026: ein Turnier mit 17 Teams und 35 Partien, an einem Abend komplett über die Plattform gespielt. Der Teil, der ein Turnier berechnet, ist besonders gründlich geprüft. Ein Fehler dort würde einen ganzen Abend verderben.
Drei Anläufe, zwei davon im Papierkorb
Oktober 2025. Ein erstes Gerüst für eine App. Dann blieb es liegen.
Februar bis März 2026. Eine echte App namens pongPartner. Sie zählte Spiele mit und hatte erste Turnierfunktionen. Durchdacht war auch, wie jemand ohne Konto mitspielt und seine Ergebnisse später in ein echtes Konto übernimmt. Das war weit genug, um weiterzumachen.
Juni 2026. Statt weiterzumachen, habe ich sechs Dokumente geschrieben: Was ist da? Was gibt es am Markt? Wohin soll es gehen? Was muss es können? Wie wird es gebaut? In welcher Reihenfolge?
Was die Untersuchung ergab
Zwei Erkenntnisse haben die Richtung gedreht.
Erstens: Apps, die nur Punkte zählen, kommen nicht weit. Vergleichbare Apps haben höchstens ein paar hundert Downloads. Das liegt nicht an schlechter Umsetzung. So eine App braucht man einmal im Jahr auf einer Feier, danach wird sie gelöscht.
Zweitens: Gebraucht wird Hilfe beim Ausrichten eines Turniers. Wer ein Turnier ausrichtet, hat ein echtes Problem, das immer wiederkommt. Zwanzig Leute, ein Spielplan, und ständig fragt jemand nach dem Stand. Das Punktezählen bringt die Leute zurück. Ein eigenes Produkt ist es nicht.
Daraus wurde der Satz, der alles Weitere bestimmt hat:
„Das Turnier verwaltet sich selbst, und niemand muss etwas installieren.“
Warum dieser Satz die App ausschloss
Der Kern ist der geteilte Link. Ein Teilnehmer bekommt eine Nachricht, tippt darauf und ist im Turnier. Er lädt nichts herunter und legt kein Konto an. Ein Zuschauer öffnet dieselbe Adresse auf dem Fernseher im Raum.
Im Web ist das selbstverständlich. Mit einer App geht es nicht ohne Hürde. Und jede Hürde schreckt genau die Leute ab, die man erreichen will.
Damit war die Entscheidung keine Geschmacksfrage mehr. In meiner schriftlichen Begründung stehen auch die Kosten. Sinngemäß: Rund 90 Dateien der App werden verworfen. Die Oberfläche hätte aber ohnehin neu gemacht werden müssen. Automatische Tests gab es keine. Und der Teil, der ein Turnier berechnet, musste sowieso neu geschrieben werden.
Auf diese Aufstellung kommt es an. Dort steht nicht „das Alte war schlecht”. Dort steht nüchtern, was verloren geht. Und dass der größere Teil der Arbeit ohnehin angefallen wäre.
Was aus dem Vorgänger überlebt hat
Nicht das Programm, aber das Denken dahinter. Wie die Daten aufgebaut sind. Welche Regeln im Spiel gelten. Und vor allem das Verfahren, mit dem ein Spieler später ein Konto anlegt und seine alten Partien behält. Das war in der alten App fertig durchdacht. Ich habe es unverändert übernommen.
Vier Monate Arbeit sind also nicht verschwunden. Verschwunden ist nur die Ausführung. Die entsteht am schnellsten wieder, wenn der Plan steht.
Wie die neue Plattform gebaut ist
Der Teil, der ein Turnier berechnet, ist vom Rest getrennt. Nur dort kann ein Fehler ein laufendes Turnier zerstören. Deshalb wird dieser Teil besonders gründlich und automatisch geprüft.
Auf die Daten darf zunächst niemand zugreifen. Jeder Zugriff muss einzeln erlaubt werden. So bleibt nichts versehentlich offen.
Deutsch und Englisch gibt es von Anfang an gleichwertig.
Für Kenner: die Technik dahinter
Next.js 16 mit React 19 und TypeScript, Supabase (Postgres, Auth, Realtime). Die Turnierlogik liegt in einem eigenen Paket ohne Laufzeitabhängigkeiten, mit in der Konfiguration erzwungenen Abdeckungsschwellen. Datenbankzugriff ist per Row Level Security standardmäßig verboten, Schreibvorgänge über mehrere Regeln laufen über Funktionen mit festgelegten Rechten. Betrieb in Docker hinter Caddy mit automatischem TLS, Auslieferung über GitHub Actions. Der Vorgänger war eine Flutter-App mit 52 Commits.
Warum das hier steht
Dieser Bericht hat die schwächsten Nutzerzahlen von allen auf dieser Seite. Trotzdem ist er mir am wichtigsten.
Auftraggeber kaufen selten eine fertige Funktion. Sie kaufen jemanden, der merkt, wenn der 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 aufgeschrieben. Gegen einen fremden Plan fällt sie leichter.
Häufige Fragen
- Wann ist ein Neubau besser als Weiterbauen?
- Wenn der Grund im Produkt liegt und nicht im Programm. So war es hier. Die Idee war: ein Turnier über einen Link, ohne Installation. Das passt ins Web. In einer App ist es ein Widerspruch. Wäre das Programm nur unordentlich gewesen, hätte Aufräumen gereicht. Die ehrliche Frage lautet: Verschwindet das Problem, wenn ich aufräume? Wenn nicht, ist der Neubau günstiger.
- Was geht bei so einer Entscheidung nicht verloren?
- Fast alles außer dem Programm selbst. Wie die Daten aufgebaut sind, welche Regeln gelten und wie ein Spieler später seine alten Spiele in ein Konto übernimmt: Das war im Vorgänger schon durchdacht. Ich habe es unverändert übernommen. Verworfen habe ich rund 90 Dateien. Das war der Teil, den ich ohnehin neu gemacht hätte.
- Warum ist der Teil, der das Turnier berechnet, vom Rest getrennt?
- Weil nur dort ein Fehler ein laufendes Turnier zerstört. Getrennt vom Rest lässt sich dieser Teil vollständig und automatisch prüfen. Wie gründlich geprüft wird, ist fest vorgeschrieben. Sinkt die Gründlichkeit, wird die Änderung nicht angenommen.
- Wie sind die Daten der Spieler geschützt?
- Zunächst ist jeder Zugriff auf die Daten verboten. Jeder einzelne Zugriff muss ausdrücklich erlaubt werden. Der umgekehrte Weg wäre: alles offen lassen und einzelne Dinge sperren. Dabei wird früher oder später etwas vergessen.