Volta — Fitness App

Der Anfang

Alles begann auf der Trainingsfläche.

Ich trainiere jeden Tag. Mit der Zeit habe ich anderen bei ihren Workouts geholfen — nicht als Trainer, sondern als jemand, der wusste, was funktioniert.

Für sie habe ich vier Figma-Screens gebaut: Home, Day One, Day Two und Day Three. Einfach, klar, nützlich. Die Leute mochten es und wollten es auf dem Handy nutzen.

Der Prototyp war dafür zu langsam. Figma auf dem Smartphone fühlte sich eher wie ein Versprechen an als wie eine echte Lösung.

Also habe ich beschlossen, daraus ein richtiges Produkt zu bauen.

Das Problem

Zwischen gutem Design und funktionierender App liegt eine große Lücke. Genau dort scheitern die meisten Side Projects.

In Figma funktioniert alles, weil wir es so definieren. In Code funktioniert erst einmal nichts — bis wir es robust gebaut haben.

Das Erlebnis war gestaltet, aber nicht gebaut. Bevor jemand eine einzige Wiederholung loggen konnte, mussten drei unsichtbare Systeme stehen: Identity (einfacher Login), Management (Pläne erstellen und zuweisen ohne DB-Handarbeit) und Execution (Workout öffnen, sehen, loggen — in unter einer Minute).

Unsichtbar für den Nutzer, aber absolut zentral für das Produkt.

Die Erkenntnis

Für Trainees sollte es sich wie ein Blatt Papier anfühlen: ein Workout, ein Tag. Tippen, starten, Sätze eintragen, fertig.

Damit es so einfach wirkt, musste das System darunter bewusst komplex sein: Echtzeit-Sync zwischen Coach und Trainee, passwortloser Login für den Gym-Alltag und ein Plan-Builder, der 20 Minuten Tabellenarbeit auf etwa 2 Minuten reduziert.

Einfachheit an der Oberfläche bedeutet fast immer Komplexität darunter. Gute Gestaltung sorgt dafür, dass Nutzer diese Komplexität nie spüren.

Die schwierigen Teile

Der schwierigste Teil war nicht das Interface-Design, sondern alles dahinter.

Jedes Feature, das zunächst simpel wirkte, brachte neue Entscheidungen mit sich: Datenmodellierung, Zustandswechsel im laufenden Plan, Konsistenz über mehrere Oberflächen hinweg.

Ich habe Fehler gemacht und Zeit verloren — nicht weil Lösungen unmöglich waren, sondern weil ich erst lernen musste, die richtigen Fragen zu stellen.

Auch bei Übungsbildern zeigte sich das Muster: Was wie ein Content-Thema aussah, wurde zu Architektur, Pipeline, Hosting und Admin-Logik.

Design-Entscheidungen haben technische Konsequenzen. Genau das habe ich in diesem Projekt konsequent gelernt.

Die Prozessfrage

Es gibt tausende Fitness-Apps. Viele davon sind zu komplex. Menschen öffnen sie, verlieren sich darin und landen wieder bei Papier.

Ich habe nicht mit einem klassischen Problemstatement begonnen. Ich habe beobachtet, womit Menschen kämpfen — und kannte die Antwort, weil ich selbst einer von ihnen war.

Genau so.

Viele behandeln Design Thinking wie ein starres Ritual. Aber warum muss das Problem immer vor der Lösung kommen? Manchmal siehst du zuerst die Lösung. Erfahrung und Mustererkennung können schneller sein als lange Vorphasen.

Das ist kein Anti-Prozess, sondern ein anderer Prozess: bauen, testen, zuhören, verbessern, erneut liefern.

Intuition auf Basis von Erfahrung ist kein Raten — sie ist eines der effizientesten Designwerkzeuge überhaupt.

Zwei Nutzer. Ein System.

Die meisten Fitness-Apps sind für eine Person gemacht: den Trainee. Hinter jedem Trainee steht aber ein Coach, der entscheidet, plant, auswertet und anpasst.

Ich habe die App deshalb für beide gebaut.

Der Trainee sieht nur das Wesentliche: heutiges Workout, klar und fokussiert.

Der Coach sieht das operative System: 61 Trainees, individuelle Pläne, Verlauf, Einschränkungen, letzte Session. Dazu ein Plan-Builder mit Drag & Drop sowie ein Live-Dashboard, das sofort aktualisiert, sobald jemand einen Satz loggt.

Gleiche Datenbasis, gleicher Echtzeit-Kern — aber zwei völlig unterschiedliche Oberflächen für zwei unterschiedliche Aufgaben.

Die Nutzer:innen

Das ist kein Konzept und keine Remix-Idee auf Basis fremder Arbeit.

Aktuell nutzen 61 Personen die App — ohne Marketing, nur durch Empfehlungen. Sie öffnen sie vor dem Training, loggen ihre Sätze, und der Coach sieht alles direkt.

Kaeien ist 68, hat Osteoporose und eine Schulterverletzung. Bea trainiert einen 4-Tage-Kraftplan. Nadia ist in Woche 3 ihres Reset-Plans.

Wenn du deine Nutzer:innen beim Namen kennst, reicht „gut genug“ nicht mehr.

Der Wandel

Nach Jahren in diesem Feld habe ich etwas gelernt, das kein Workshop vermitteln kann.

Ich habe mich von „Wie sieht es aus?“ zu „Was kostet es und wie fließen die Daten?“ bewegt.

Das sind keine reinen Entwicklerfragen — das sind Produktdesign-Fragen. Ein scheinbar simples Feature kann drei Architekturentscheidungen verlangen, bevor die erste Zeile Code entsteht. Durch Lazy-Caching für Gemini-Zitate konnten API-Kosten um 95% gesenkt werden. Diese Erkenntnis kam aus Datenverständnis, nicht aus einem Design-Tool.

Die Lücke zwischen Design und Engineering ist kleiner, als viele denken. Wer sie überbrückt, kann ein Produkt wirklich führen.

Das Ergebnis

• 95% API-Kosten eingespart
• 10x Schnellere Planerstellung
• 97% Nutzerbindung
• 61 Aktivierte Nutzer:innen
• 383 Übungen mit Bewegungsanleitung

Was die Athletinnen sagen

Was ich gelernt habe

Der wertvollste Moment war keine Design-Entscheidung. Es war der Moment, als Eve nach ihren Logs fragte und ich nichts zeigen konnte. Diese Lücke zwischen gebautem System und echtem Bedarf wurde innerhalb weniger Tage zu einem neuen Feature.

Ich habe dieses Projekt gestartet, um einigen Menschen besseres Training zu ermöglichen. Dabei habe ich mehr über Produkt, Daten und Engineering gelernt als in Jahren klassischer Handoffs.

Die App heißt heute Volta — benannt nach dem elektrischen Signal vom Gehirn zum Muskel, also dem Moment vor der Bewegung.

Wir shippen weiter. Injury-aware Exercise Gating ist als Nächstes dran.