Travel tracker
2026 — planningIn design
Polarsteps is lovely and it throws your data away. This is the version for people who want the numbers: deep stats, raw exports, real route reconstruction. Personal use first — it goes public only if it proves out.
Role — Sole developer — architecture, mobile, backend, geospatial service
- Platform
- Android first
- New language
- Kotlin
- Geospatial
- Rust + PostGIS
- Redis
- None
The constraint that shaped it
Background GPS on Android has to be reliable and free. That one requirement decided the whole mobile stack: React Native's dependable background-location option is a paid library, while native Android's is free and standard. So it's Kotlin, learned from scratch, instead of the framework I already know.
Built from a competitor's gaps
The feature list isn't a wishlist. Each item is something the incumbent does badly or refuses to do, written down while I was actually using it on trips.
Editable GPS tracks. A bad point in Polarsteps is permanent. Here a track is correctable, because a phone in a pocket in a tunnel produces garbage, and pretending otherwise poisons every statistic downstream.
Map-matching and snap-to-road. Sparse points joined by straight lines isn't a route. Reconstructing the real path is what makes the distance figure mean anything.
Manual trip start and end. No midnight boundary deciding that one drive was two separate days.
A visible tracking-health indicator. The worst failure here is silent: permissions get revoked, background execution gets killed, and you find out weeks later that a whole country is missing. If tracking breaks, the app should say so on its own face.
Real exports. CSV and JSON of the raw data, plus PDF reports with average speed, elevation and max/min temperature — not just a printed photo book.
Region, state and country visited as a first-class stat, rather than something you count by eye off a map.
Google Photos linked by EXIF, matching on GPS and timestamp with a manual override, instead of the weak suggestion model.
Why this stack
Kotlin over React Native, decided on one requirement rather than preference. Reliable background GPS is the product, and on React Native the dependable option is a paid library while the native Android one is free and standard. Learning a new language was cheaper than that dependency.
Jetpack Compose with Material 3 defaults, leaning on the design system instead of fighting it. Design isn't my strongest axis and Material 3 is a better designer than I am.
Mapbox over Google Maps, chosen after finding out it's what Polarsteps itself uses — a reasonable signal for this exact workload.
A Rust service for the geospatial work: route simplification, map-matching, and crunching speed, elevation and distance statistics. This is the shape of workload where Rust earns its place rather than being chosen for fun.
PostgreSQL with PostGIS, and pg-boss for jobs, which means no Redis at all. At this scale Redis would be a second piece of infrastructure to keep alive for no benefit.
NestJS on the backend, reusing the architecture blueprint from previous projects on separate infrastructure. The fourth project to start from that document instead of a blank page.