Bike Assistant
Jedes Teil im Takt halten
Eine SaaS, die aus deinen Ride-Daten automatisch den Verschleiß jedes Bauteils deiner Räder verfolgt, dann vorhersagt und erinnert, wann Teile Service brauchen — die Wartungsschicht, die Strava nie hatte. Aktuell in Closed Beta, vor dem öffentlichen MVP-Launch.
- Rolle
- Mitgründer · Full-Stack (Backend, Daten, APIs & Frontend)
- Stack
- Next.js 16 · React 19 · TypeScript · TanStack Query · Zod · Node / Express · Supabase · Tailwind · Storybook · Chromatic · Strava API · Vercel · Railway · Cloudflare
Das Problem
Strava trackt deine Fahrten, aber nichts trackt dein Rad. Ketten müssen nach Plan neu gewachst werden, Antrieb und Reifen verschleißen mit der Distanz, und über mehrere Räder hinweg kann sich niemand merken, was fällig ist. Fahrer merken es erst, wenn unterwegs etwas versagt.
Die Idee
Bike Assistant behandelt jedes Bauteil als verfolgtes Teil mit eigenem Verschleißbudget. Es importiert die gefahrene Distanz automatisch aus Strava, ordnet sie dem richtigen Rad und den richtigen Teilen zu und zeigt smarte Erinnerungen — Kette neu wachsen, Austauschfenster — plus Auswertungen wie Kosten pro Kilometer und den Zustand über mehrere Räder hinweg.
Unter der Haube
Keine App — ein System
Ride-Daten fließen durch eine bewusst schlanke Multi-Service-Architektur. Jede Stufe ist ein eigenes Deployable, verbunden durch einen einzigen typisierten Vertrag.
Strava rein → ein Wartungsplan raus.
Die typisierte API-Grenze, gegen die beide Seiten bauen — eine versionierte Source of Truth, kein Drift.
Domänenorientierter Service — Sync, Ingestion, Gear, Rides, Wartung — plus die Strava-Pipeline.
Die App selbst: eine TanStack-Query-Datenschicht und Real-Mode-Flows für Teile & Wartung.
Veröffentlichte @bike-assistant/ui-Komponentenbibliothek mit Visual-Regression-Testing.
Schema, Umgebungen und der Dev → Prod-Pfad, entlang dessen das ganze System deployt.
Jedes Repo ist typisiert und isoliert getestet — Vitest und Nodes nativer Test-Runner, Visual-Regression-Gating des Design-Systems über Chromatic, alles in GitHub Actions abgesichert, bevor etwas ausgeliefert wird.
Closed-Beta-Vorschau
So sieht es heute aus
Das Dashboard zeigt deine letzten Fahrten, eine überfällige Kettenwachs-Warnung und den Live-Verschleiß pro Teil über alle Räder — alles automatisch aus Strava abgeleitet, nichts von Hand zu erfassen. Dieselbe Ansicht skaliert von dieser Mobile-PWA bis zum vollen Tablet- und Desktop-Layout.
Gestaltet von meinem Mitgründer · in aktiver Entwicklung vor dem öffentlichen Launch.
Was ich verantworte
Ich habe das Produkt mit einem Design-/Produkt-Partner mitgegründet, der Design und UX verantwortet. Ich verantworte den Datenpfad end-to-end — und zunehmend das Engineering, das aus dem Design eine funktionierende App macht:
- Eine idempotente, fortsetzbare Strava-Ingestion-Pipeline — OAuth, Webhooks für automatischen Sync, cursor-basiertes Fetching und ein Background-Job-Runner, der mitten im Lauf wieder aufsetzen kann, ohne Distanz doppelt zu zählen.
- Ein modularer TypeScript/Express-Service über Supabase (Postgres, Auth, Realtime), nach Domänen organisiert — Sync, Ingestion, Gear, Rides, Wartung — hinter einer Zod-typisierten, contract-first API-Grenze, die mit dem Frontend geteilt wird.
- Das Datenmodell, das Aktivitäten → Räder → Teile → Verschleiß abbildet — Ketten als Teile, Wachszyklen, Dichtmilch und Serviceintervalle — auf dem alles andere aufbaut.
- Frontend-Umsetzung: die PWA an das Live-Backend anbinden — die TanStack-Query-Datenschicht und die Real-Mode-Flows für Teile, Wartung und Einstellungen (Lifecycle, History bearbeiten/löschen, Sync) — auf Basis unseres gemeinsamen Designsystems.
Die größere Idee
Zu zweit gebaut — mit einer Flotte von Agenten
Bike Assistant ist nicht nur das Produkt — sondern auch, wie es gebaut ist. Das ganze System ist so konstruiert, dass Menschen und KI-Agenten dasselbe Produkt gemeinsam ausliefern: zwei Gründer und mehrere KI-Tools arbeiten täglich über ein gemeinsames Setup an dieser Multi-Repo-Codebase. Die contract-first, multi-service Form oben ist kein Zufall — genau sie macht paralleles Mensch-und-Agent-Arbeiten sicher.
Für mich ist es ein Beleg dafür, was Produktarbeit heute sein kann: Wenn Produktdenken, Product Engineering und Kreativität auf die Bereitschaft treffen, tief zu graben und dranzubleiben, wird aus einer Idee ein System, das wirklich läuft. Diese Mischung — weit mehr als ein einzelnes Tool — macht so etwas möglich.
Eine tool-agnostische Einstiegsdatei lädt die richtige Rolle, Konventionen und Berechtigungen pro Person und pro Agent — kein generischer Prompt.
Schrittweise offengelegte Skills und Live-Tool-Zugriff — Linear, Supabase, Railway, Vercel, Figma — damit Agenten am echten System handeln, nicht an dessen Beschreibung.
Schnittstellen werden vereinbart und veröffentlicht, bevor die konsumierende Arbeit beginnt — so driften asynchrone Übergaben zwischen Menschen und Agenten nie auseinander.
Ein Issue, ein Branch, ein PR — und ein unabhängiger Agent prüft die Arbeit hinter Merge-Safety-Gates vor jedem menschlichen Merge.
Status
In Closed Beta mit einer kleinen Gruppe von Pilot-Fahrern. Die Marketing-Seite ist live, API und App laufen auf unserer Cloud-Infrastruktur, vor dem Produktions-Cutover. Wir sind ein Zwei-Gründer-Team auf dem Weg zu einem öffentlichen MVP-Launch in den kommenden Wochen — und ich rahme das ehrlich als geteilte Verantwortung: Produktdesign liegt bei meinem Mitgründer, während Daten, Backend und das Real-Mode-Engineering der App von mir kommen.