Klaimo: Cycling Tracking Where You Conquer Real Territory

A fitness app has to record a ride and evaluate it. A gamified cycling app, in which riding claims real-world territory, has to turn that same recording into something fundamentally different: a line has to become an area — and that area has to be reconciled with everything on the map that already belongs to someone. The centre of gravity shifts out of the frontend and into geometry: building polygons, merging them, intersecting them, subtracting them. That is precisely the part that decides how the game feels and what it costs to run.

What makes it harder is that raw GPS is not a clean path. Positions drift, jump around in dense urban canyons, arrive at uneven intervals and cut out in tunnels or whenever the signal drops. Turn such a sequence of points straight into a polygon and you get self-intersections, outliers and geometrically invalid shapes — and invalid geometry brings down every operation layered on top of it. So before any of the game mechanics comes data preparation.

Then there is the question of authority. The moment leaderboards and teams exist, the result has to be the same for everyone. A world state that each handset computes for itself would be neither consistent nor verifiable. And the cost profile behaves differently from plain tracking: recording a route costs roughly the same every time, intersecting new areas against a map that keeps filling up does not. Processing geospatial data in real time while still rendering a smooth live map was the actual task — on top of subscriptions across two stores, a wearable integration and the store launch, all of it handled end to end in-house.

The first decision was where to draw the line between app and server. The Flutter app records and displays; the backend decides what counts. The compute-heavy geo math — areas, polygons, intersections — runs in a Go service on Google Cloud Run that scales automatically under load. The map therefore rests on a single source of truth, leaderboards and team scores stay comparable, and the computation does not sit on a device that is already busy logging positions for the length of an entire ride.

Go suits this kind of work because polygon operations are CPU-bound rather than waiting on I/O: compiled code, fast startup, a small memory footprint, concurrency without much ceremony. Cloud Run adds load-based autoscaling on top — fewer instances during quiet periods, more when demand arrives. The load profile of a leisure app is predictably uneven (after work, weekends, good weather), and request-based autoscaling is built for exactly that. The flip side: the service has to be stateless, and any state belongs in the data layer.

On the map, claimed territories are drawn through custom Mapbox layers rather than as individual overlay objects placed on top of the map. The difference is in the rendering: areas expressed as layers are drawn and styled by the map renderer itself and remain part of the map while panning and zooming, instead of floating above it as an ever-growing set of separate elements. The live map, the leaderboards and the team views all read from the same server-side state.

Anything that is not the core was integrated rather than built: subscriptions run cross-platform through RevenueCat, so there is one subscription status instead of two separate state machines for the App Store and the Play Store; fitness data comes in via the Garmin API, so riders can keep using the recording hardware they already own. The guiding principle: build what makes the product what it is — geo logic, game mechanics, map rendering — and use established services for the rest. Architecture, backend and the launch in both stores were all in one pair of hands.

• Real-time territory conquest
• Interactive live map (Mapbox)
• Leaderboards & teams
• Subscription model (RevenueCat)
• Garmin integration
• Go geo-backend on Cloud Run

An in-house product by SB-Techworks – from architecture and the Go backend to launch, published on the App Store and Play Store. Klaimo shows that even compute-heavy consumer apps with live geodata can ship to production as a solo project.

For comparable projects — anywhere movement or sensor data turns into a binding result — the decisive question is not how to record GPS, but where it is decided what counts. As soon as leaderboards, competitions or rewards are involved, that computation belongs on the server; retrofitting it later is close to impossible, because past states cannot be reconstructed without a server-side source. It is equally worth looking early at how the workload grows: recording costs a constant amount, intersecting geometry gets more expensive with every additional record in the map. A stateless, autoscaling compute service alongside the application itself is a durable pattern for that — and not only for geospatial data.

The second transferable point is about scope. Every supporting function you build yourself — billing, subscription management, map rendering, integrations with third-party platforms — is maintenance forever, and maintenance grows while development capacity does not. In practice, what decides feasibility for a gamified fitness app is less the game idea than how much gets custom-built around it. The better move is to concentrate original development on the part that makes the product distinguishable and accept established services for everything else — including the dependency that comes with them.