Klaimo: Fahrrad-Tracking, bei dem man echte Gebiete erobert

Eine Fitness-App muss eine Fahrt aufzeichnen und auswerten. Eine gamifizierte Fahrrad-App, in der beim Fahren reale Gebiete erobert werden, muss aus derselben Aufzeichnung etwas grundlegend anderes machen: aus einer Linie eine Fläche – und diese Fläche gegen alles rechnen, was auf der Karte bereits jemandem gehört. Damit verschiebt sich der Schwerpunkt vom Frontend in die Geometrie: Polygone bilden, zusammenfassen, verschneiden, voneinander abziehen. Genau dieser Teil entscheidet über Spielgefühl und Betriebskosten.

Erschwerend kommt hinzu, dass GPS-Rohdaten kein sauberer Streckenzug sind. Positionen driften, springen in enger Bebauung, kommen in ungleichmäßigen Abständen und brechen in Tunneln oder bei Signalverlust ab. Wer aus so einer Punktfolge unmittelbar ein Polygon bildet, erhält Selbstüberschneidungen, Ausreißer und geometrisch ungültige Formen – und ungültige Geometrie bringt jede darauf aufbauende Verschneidung zu Fall. Vor der eigentlichen Spielmechanik steht deshalb Datenaufbereitung.

Dazu kommt die Frage der Verbindlichkeit: Sobald es Ranglisten und Teams gibt, muss das Ergebnis für alle dasselbe sein. Ein Weltzustand, den jedes Endgerät für sich berechnet, wäre weder konsistent noch überprüfbar. Und der Aufwand verhält sich anders als bei reinem Tracking: Eine Streckenaufzeichnung kostet immer ungefähr gleich viel, das Verschneiden neuer Flächen mit einer zunehmend gefüllten Karte nicht. Geodaten in Echtzeit zu verarbeiten und trotzdem eine flüssige Live-Karte zu zeigen, war die eigentliche Aufgabe – zusätzlich zu Abos über zwei Stores, Wearable-Anbindung und Store-Launch, alles aus einer Hand.

Die erste Entscheidung war der Schnitt zwischen App und Server. Die Flutter-App erfasst und stellt dar; was gilt, entscheidet das Backend. Die rechenintensive Geo-Mathematik – Flächen, Polygone, Überschneidungen – läuft in einem Go-Dienst auf Google Cloud Run, der bei Last automatisch skaliert. Damit beruht die Karte auf einer einzigen Quelle, Ranglisten und Team-Wertungen sind vergleichbar, und die Rechenlast liegt nicht auf einem Gerät, das parallel über eine ganze Fahrt hinweg Positionen aufzeichnen soll.

Go passt zu dieser Art Arbeit, weil Polygonoperationen CPU-gebunden sind und nicht auf Ein- und Ausgabe warten: kompilierter Code, kurze Startzeiten, geringer Speicherbedarf, Nebenläufigkeit ohne großen Überbau. Cloud Run ergänzt das um lastabhängige Autoskalierung – in Ruhephasen laufen entsprechend weniger Instanzen, bei Andrang kommen welche dazu. Das Lastprofil einer Freizeit-App ist erwartbar ungleichmäßig (Feierabend, Wochenende, gutes Wetter), und genau dafür ist eine anfragebasierte Autoskalierung gebaut. Die Kehrseite: Der Dienst muss zustandslos sein, jeder Zustand gehört in die Datenhaltung.

Auf der Karte werden die eroberten Territorien über eigene Mapbox-Layer gezeichnet statt über einzelne, auf die Karte gesetzte Overlay-Objekte. Der Unterschied liegt im Rendering: Flächen als Layer werden vom Karten-Renderer selbst gezeichnet und gestylt und bleiben beim Zoomen und Verschieben Teil der Karte, statt als wachsende Menge einzelner Elemente über ihr zu schweben. Live-Karte, Ranglisten und Teams greifen dabei auf denselben serverseitigen Stand zu.

Alles, was nicht den Kern ausmacht, wurde angebunden statt gebaut: Abos laufen plattformübergreifend über RevenueCat, sodass es einen Abostatus gibt statt zweier getrennter Zustandsautomaten für App Store und Play Store; Fitnessdaten kommen über die Garmin-API herein, damit die gewohnte Aufzeichnungshardware weiter genutzt werden kann. Die Leitlinie dahinter: selbst entwickeln, was das Produkt ausmacht – Geo-Logik, Spielmechanik, Kartendarstellung – und für den Rest etablierte Dienste nehmen. Architektur, Backend und Launch in App Store und Play Store lagen dabei in einer Hand.

• Echtzeit-Eroberung von Territorien
• Interaktive Live-Karte (Mapbox)
• Ranglisten & Teams
• Abo-Modell (RevenueCat)
• Garmin-Anbindung
• Go-Geo-Backend auf Cloud Run

Eigenentwicklung von SB-Techworks – von der Architektur über das Go-Backend bis zum Launch, veröffentlicht im App Store und im Play Store. Klaimo zeigt, dass auch rechenintensive Consumer-Apps mit Live-Geodaten als Solo-Projekt in Produktion gehen können.

Für vergleichbare Vorhaben – überall dort, wo Bewegungs- oder Sensordaten zu einem verbindlichen Ergebnis werden – ist die entscheidende Frage nicht, wie sich GPS aufzeichnen lässt, sondern wo entschieden wird, was gilt. Sobald Ranglisten, Wettbewerbe oder Belohnungen im Spiel sind, gehört diese Berechnung auf den Server; nachträglich lässt sich das kaum reparieren, weil vergangene Zustände ohne serverseitige Quelle nicht rekonstruierbar sind. Ebenso lohnt der frühe Blick auf das Wachstumsverhalten: Aufzeichnen kostet konstant, das Verschneiden von Geometrie wird mit jedem zusätzlichen Datenbestand teurer. Ein zustandsloser, autoskalierender Rechendienst neben der eigentlichen Anwendung ist dafür ein tragfähiges Muster – und zwar nicht nur bei Geodaten.

Der zweite verallgemeinerbare Punkt betrifft den Zuschnitt: Jede selbst gebaute Nebenfunktion – Abrechnung, Abo-Verwaltung, Kartenrendering, Anbindung an Fremdplattformen – ist dauerhafte Wartung, und Wartung wächst mit, während die Entwicklungskapazität es nicht tut. Erfahrungsgemäß entscheidet bei gamifizierten Fitness-Apps weniger die Spielidee über die Machbarkeit als die Frage, wie viel rundherum selbst gebaut wird. Sinnvoller ist, die Eigenentwicklung auf den Teil zu konzentrieren, der das Produkt unterscheidbar macht, und für alles andere etablierte Dienste zu akzeptieren – einschließlich der Abhängigkeit, die man sich damit einhandelt.