RED FURY: Warum ich mir meinen eigenen Trainingstracker gebaut habe
Aus einer kleinen PWA für mein eigenes Training wurde nach und nach ein vollständiges Softwareprojekt.
Ich wollte eigentlich keine eigene Fitness-App bauen. Ich wollte nur meine Trainingspläne und Sätze so erfassen, wie es für mich sinnvoll ist.
Schnell, ohne unnötige Menüs und vor allem auch dann, wenn das WLAN im Gym wieder einmal praktisch nicht funktioniert.
Aus dieser recht überschaubaren Idee entstand RED FURY. Zuerst als kleine PWA mit einigen Übungen und einer einfachen Möglichkeit, mein Training zu dokumentieren. Inzwischen ist daraus ein vollständiger Trainingstracker mit Live-Workouts, Statistiken, Synchronisierung, Backups und einem eigenen Bereich für Dehnen geworden.
Der Weg dorthin war deutlich aufwendiger, als ich am Anfang erwartet hatte.
Ich wollte nicht noch eine Fitness-App
Natürlich gibt es bereits mehr als genug Apps für Krafttraining. Einige davon sind gut, viele können deutlich mehr, als ich jemals brauchen werde.
Genau das war aber ein Teil des Problems.
Ich wollte keine Plattform mit Community, Challenges, vorgefertigten Trainingsprogrammen und fünf verschiedenen Abomodellen. Ich wollte ein Werkzeug für mein eigenes Training.
Im Gym brauche ich im Grunde nur wenige Dinge:
- meinen aktuellen Trainingsplan
- die Werte aus dem letzten Workout
- eine schnelle Eingabe für Gewicht und Wiederholungen
- eine saubere Übersicht über meine Entwicklung
- die Sicherheit, dass meine Daten nicht verloren gehen
Das klingt zunächst nicht besonders kompliziert. Sobald man die App aber wirklich während des Trainings verwendet, werden aus diesen fünf Punkten schnell deutlich mehr Anforderungen.
Ein neuer Satz soll mit möglichst wenigen Eingaben angelegt sein. Vorwerte müssen sofort sichtbar sein. Warm-up-Sätze dürfen die eigentliche Auswertung nicht verfälschen. Änderungen am Trainingsplan sollen alte Workouts nicht nachträglich verändern. Und wenn das Internet ausfällt, darf die App nicht einfach stehen bleiben.
Die meisten dieser Punkte wären mir bei einer rein theoretischen Planung vermutlich gar nicht aufgefallen. Sie entstanden erst dadurch, dass ich RED FURY selbst im Training benutzt habe.
Aus einer kleinen PWA wurde immer mehr
Die erste Version war bewusst einfach. Übungen anlegen, Trainingspläne zusammenstellen, Workout starten und Sätze erfassen.
Damit war die Grundlage vorhanden. Gleichzeitig begann damit das eigentliche Problem eigener Software: Sobald etwas grundsätzlich funktioniert, fallen einem sofort zehn Dinge auf, die noch besser gehen könnten.
Ich wollte die Werte aus dem letzten Training direkt übernehmen können. Daraus entstanden Vorwerte und kompakte Plus- und Minus-Schritte.
Ich wollte nicht jedes Aufwärmgewicht selbst berechnen. Also kam ein Warm-up-Generator dazu.
Ich wollte wissen, ob ich mich bei einer Übung tatsächlich verbessert habe. Daraus wurden persönliche Rekorde, Progressionsvorschläge und detailliertere Statistiken.
Ich wollte ein vergessenes Workout nachtragen können. Also brauchte die App eine manuelle Erfassung, Bearbeitung und Duplizierung bestehender Einheiten.
Später kam ein eigener Bereich für Beweglichkeit hinzu. Heute enthält RED FURY 60 Dehn- und Mobilisationsübungen, eigene Routinen und geführte Sessions mit Halte- und Wechselzeiten.
Keine dieser Funktionen war Teil eines großen Plans. Fast alles entstand aus einem konkreten Problem, das während der Nutzung aufgefallen ist.
Offline ist im Gym kein Sonderfall
Eine der wichtigsten Entscheidungen war, RED FURY nicht wie eine klassische Web-App zu behandeln.
In vielen Anwendungen wird eine Eingabe direkt an einen Server geschickt. Ist die Verbindung schlecht, dauert der Vorgang länger oder schlägt fehl. Bei einer Trainings-App ist das besonders störend. Ich möchte nach einem Satz nicht prüfen, ob das WLAN gerade funktioniert.
Deshalb arbeitet RED FURY local-first.
Eine Eingabe wird zuerst direkt auf dem Gerät gespeichert. Die App reagiert sofort und bleibt auch ohne Verbindung vollständig nutzbar. Sobald wieder Internet vorhanden ist, werden die Änderungen mit der Cloud synchronisiert.
Das klingt nach einem technischen Detail, verändert aber die komplette Nutzung. Ich kann die App im Gym öffnen, mein Training durchführen und muss mir über Empfang oder WLAN keine Gedanken machen.
Gerade diese unsichtbaren Funktionen haben am Ende deutlich mehr Arbeit verursacht als viele sichtbare Features.
Ein neuer Statistik-Block ist schnell erklärt. Schwieriger ist sicherzustellen, dass eine Eingabe niemals auf eine Netzwerkantwort wartet, mehrere geöffnete Instanzen keinen Synchronisationssturm verursachen und ein App-Update nicht mitten im Workout die Seite neu lädt.
Man merkt diese Dinge kaum, solange sie funktionieren. Sobald sie nicht funktionieren, ist die gesamte App unbrauchbar.
Die Technik ist Mittel zum Zweck
RED FURY ist als installierbare Progressive Web App gebaut. Technisch basiert sie unter anderem auf React, TypeScript, Dexie und Supabase.
Für mich war aber nie das Ziel, möglichst viele moderne Technologien in einem Projekt unterzubringen. Die Technik musste konkrete Anforderungen erfüllen.
Dexie speichert die Trainingsdaten lokal im Browser. Supabase übernimmt Anmeldung, Datenbank und Synchronisierung zwischen Geräten. Die PWA lässt sich auf dem Smartphone installieren und verhält sich weitgehend wie eine normale App.
Entscheidend ist nicht, welche Bibliothek hinter einer Funktion steckt. Entscheidend ist, dass ich im Training auf „+ Satz“ drücke und der Satz sofort da ist.
Diese Perspektive hat auch viele Entscheidungen vereinfacht. RED FURY muss aktuell keine Plattform für Millionen Nutzer sein. Die App ist in erster Linie für mich und einige freigeschaltete Accounts gebaut.
Dadurch kann sie bewusst speziell sein.
Ich muss nicht jeden denkbaren Trainingsstil abdecken. Ich kann Funktionen so gestalten, wie sie für meine Abläufe sinnvoll sind. Und ich kann Dinge weglassen, die zwar in eine typische Fitness-App gehören würden, mir persönlich aber keinen Mehrwert bieten.
Ohne KI hätte ich das Projekt so nicht gebaut
Ich bin kein klassisch ausgebildeter Softwareentwickler. Mein Hintergrund liegt in Gestaltung, Marketing, E-Commerce und UX.
Trotzdem kann ich heute ein Projekt wie RED FURY umsetzen. Ein wesentlicher Grund dafür sind KI-Werkzeuge wie Codex, die mich bei Architektur, Implementierung, Tests und Dokumentation unterstützen.
Das bedeutet allerdings nicht, dass man einer KI einmal „Baue mir eine Fitness-App“ schreibt und anschließend ein fertiges Produkt erhält.
Die eigentliche Arbeit verschiebt sich.
Ich muss sehr genau beschreiben, welches Problem gelöst werden soll. Ich muss Entscheidungen treffen, Ergebnisse prüfen und erkennen, wenn eine technisch saubere Lösung in der Praxis trotzdem schlecht funktioniert. Außerdem braucht ein wachsendes Projekt klare Regeln, Dokumentation und Tests. Sonst produziert auch eine gute KI mit jeder Änderung neue Widersprüche.
Mit zunehmendem Umfang wurden deshalb Dinge wichtig, die ich am Anfang kaum auf dem Schirm hatte:
- feste Architekturregeln
- nachvollziehbare Versionen und Changelogs
- automatisierte Tests
- Qualitätsprüfungen vor jedem fertigen Stand
- klare Vorgaben für Daten, Synchronisierung und Offline-Verhalten
Die KI kann sehr viel Code schreiben. Sie weiß aber nicht automatisch, welche App die richtige ist.
Diese Verantwortung bleibt bei mir.
Gestaltung endet nicht beim Interface
Anfangs dachte ich bei UX vor allem an Navigation, Abstände, Buttons und verständliche Eingabefelder.
Bei RED FURY wurde mir noch einmal deutlich, dass gute Nutzererfahrung wesentlich früher beginnt.
Es ist UX, wenn eine Eingabe sofort gespeichert wird.
Es ist UX, wenn ein Update nicht mitten im Training startet.
Es ist UX, wenn ein Nutzer klar sieht, ob noch Daten synchronisiert werden müssen.
Es ist UX, wenn eine Statistik nicht nur korrekt berechnet ist, sondern auch sinnvoll einordnet, ob ein Wert wirklich eine neue Bestleistung darstellt.
Viele der wichtigsten Designentscheidungen sind im fertigen Interface kaum sichtbar. Sie bestimmen trotzdem, ob sich eine App verlässlich oder anstrengend anfühlt.
Gerade diese Verbindung aus Gestaltung, Produktlogik und technischer Umsetzung macht das Projekt für mich interessant.
Der Umfang wächst schneller als erwartet
Eigene Projekte haben einen gewissen Sog.
Man beginnt mit einer kleinen, klaren Idee. Dann verbessert man einen Ablauf, ergänzt eine Auswertung und löst einen Sonderfall. Jede einzelne Änderung wirkt überschaubar. In Summe entsteht daraus irgendwann ein System, das gepflegt werden muss.
Das ist auf der einen Seite motivierend. RED FURY ist heute deutlich näher an dem Trainingstool, das ich tatsächlich haben wollte.
Auf der anderen Seite muss ich regelmäßig entscheiden, was nicht gebaut wird.
Nicht jede gute Idee verbessert die App. Manche Funktionen erhöhen nur den Umfang. Andere passen vielleicht grundsätzlich zu Fitness-Apps, aber nicht zu RED FURY.
Eine wichtige Aufgabe besteht deshalb darin, das Projekt nicht einfach immer größer zu machen, sondern klarer.
Der eigene Anwendungsfall hilft dabei. Ich kann jede Idee an einer einfachen Frage messen:
Würde ich diese Funktion während meines eigenen Trainings wirklich verwenden?
Ist die Antwort unklar, muss sie wahrscheinlich nicht sofort umgesetzt werden.
Wo RED FURY heute steht
RED FURY deckt inzwischen meinen gesamten Trainingsablauf ab.
Ich kann Pläne erstellen, Workouts starten, Sätze schnell dokumentieren und vergangene Werte direkt übernehmen. Die App erkennt persönliche Bestleistungen, zeigt Entwicklungen in Statistiken und sichert meine Daten lokal sowie in der Cloud.
Zusätzlich kann ich eigene Dehnroutinen zusammenstellen und mich mit einem geführten Timer durch die Übungen führen lassen.
Trotzdem betrachte ich die App nicht als fertig.
Bei fast jedem echten Training fällt mir etwas auf, das einfacher, schneller oder verständlicher sein könnte. Manchmal ist es nur eine Beschriftung. Manchmal führt eine kleine Beobachtung zu einer grundlegenden Änderung im Datenmodell oder in der Synchronisierung.
Genau das ist vermutlich der größte Unterschied zwischen einem Demo-Projekt und einem Werkzeug, das man selbst dauerhaft verwendet.
Ein Demo-Projekt muss einmal funktionieren. Ein echtes Werkzeug muss jeden Tag funktionieren.
Was ich aus dem Projekt mitnehme
RED FURY hat mir vor allem drei Dinge gezeigt.
Erstens: Ein kleines persönliches Problem ist oft ein besserer Ausgangspunkt als eine möglichst große Geschäftsidee. Ich wusste von Beginn an, für wen ich die App baue und woran ich erkenne, ob sie funktioniert.
Zweitens: Die schwierigsten Teile einer Anwendung sind häufig nicht die sichtbaren Funktionen. Zuverlässigkeit, Datenhaltung, Fehlerfälle und Updates wirken unspektakulär, entscheiden aber über die tatsächliche Qualität.
Drittens: KI senkt die technische Einstiegshürde enorm, ersetzt aber weder Produktdenken noch Verantwortung. Je mehr eine KI umsetzen kann, desto wichtiger wird die Fähigkeit, Anforderungen sauber zu formulieren, Entscheidungen zu treffen und Ergebnisse kritisch zu bewerten.
Ich wollte ursprünglich nur meine Sätze vernünftig loggen.
Am Ende habe ich dabei deutlich mehr über Softwareentwicklung, Produktdesign und den sinnvollen Einsatz von KI gelernt, als ich erwartet hatte.
