RIDR

Overview

RIDR is a mountain biking app built around community rather than leaderboards. Riders track their rides with GPS, hold records at the trail level, earn XP and badges, take on challenges, and follow each other in a social feed. The trail catalog is powered by OpenStreetMap data.

I was at RIDR GmbH from March to September 2026, one of two engineers. The mobile app was my responsibility end to end: features, releases, and the parts of the backend the app depends on.

How it's built

The app is React Native on Expo, written in TypeScript, on a Convex backend. Convex keeps the feed, challenges, and ride state reactive without a sync layer of our own. GPS tracking runs through the ride lifecycle (record, pause, resume, save) and resolves rides against trail geometry so records attach to the trail, not just the rider.

The trail catalog comes from OpenStreetMap: a bulk import of mountain bike trails with automated classification and elevation added from AWS terrain tiles. It powers the Explore map, which 77% of monthly actives open.

The trail review tool

Trails arrive from OpenStreetMap as fragments. One named run is often a dozen separate ways, split wherever a mapper happened to break them, and the source keeps moving underneath you. I built the admin tool for turning that into a catalog: a map of candidate segments, the chains they form when you follow them end to end, a merge preview of what joining a set would produce, drift detection against the OSM source, and a decide step for accepting, editing or rejecting what came in.

It was built for a moderation model, where a person curated trails before riders saw them. The product went the automated route instead. 80 files across the web tool and the backend models, and 29 of its 34 commits are mine.

Keeping rides

In July, 48% of ride uploads were failing. Two waves of fixes, idempotent uploads keyed by a client ID and dedup of duplicate sessions, brought that under 1% by late August. A crash-recovery flow restored 146 rides that were interrupted mid-session. On the GPS side: stationary-drift gating so standing still doesn't count as movement, and speed measured over a sustained window rather than single fixes.

Shipping

RIDR went to the stores in June 2026. In the three months since: 4,500+ riders, 3,000+ monthly actives (roughly doubling from June to August), 5,000+ GPS ride sessions, and 1,800+ rides in the database. Nineteen releases in that window, store builds and over-the-air updates, at about one a week, each gated by tests, type checks, and lint in CI.

How I ship

A stakeholder request becomes a task on our ClickUp board, scoped small enough for an agent to take. Each task gets its own git worktree, so several Claude sessions, in the cloud and against two or three simulators, run in parallel without touching each other's files. The codebase is arranged for that kind of work: stable module boundaries, and a shared skills-and-memory docs layer every agent session loads, which keeps generated code consistent instead of re-explaining the rules each time. In six months this has carried 1,200+ commits across 167 pull requests from me.