odo

The problem is not the technology. The problem is the model. These tools treat personalization as a filter applied on top of distance optimization — a layer you add after the route exists. odo inverts this. Rider intent is not a constraint on the route. It is the origin of the route. Scenery, surface, shade, wind, safety — these are not preferences you toggle. They are the inputs from which the route is generated.

This changes what the system has to do. It is not a routing problem. It is a data translation problem: how do you take a rider's intent and convert it into API parameters, weighted signals, and explainable output that a cyclist can actually trust? How do you build something that shows its reasoning — so that when the app says "this is your scenic loop," the rider understands why, and agrees?

The design challenge was not the interface. It was the pipeline behind the interface — and making that pipeline legible enough to feel like a recommendation, not a black box.

The tools that exist are built primarily for two use cases: athletic performance tracking and navigation during a ride. Neither is designed for the planning phase, and neither takes the rider's intent as a primary input. Komoot offers terrain-type filtering. Strava provides segment data for athletes. Outdooractive aggregates trail information. Wikiloc crowdsources routes from other users. All of them default to the same underlying model: optimize for distance and time, then let the rider filter the results.

The result is a particular kind of frustration that cyclists describe consistently in our research: the tools give you options, but the options feel arbitrary. You don't know why the app chose this route over another. You don't know if the "scenic" option is actually scenic, or just labeled that way. You don't know how the gradient compares between routes, or which one has the most shade at 10am, or whether the gravel sections are rideable on a road bike.

Trust requires explanation. The current generation of route planners does not explain.

We assumed cyclists would be roughly split between loop routes and point-to-point. The survey showed a strong preference for loops — routes that return to the start — across all rider types. This is not a small detail. It means the entire routing model needs to generate loops, not paths. Existing tools are built around paths. odo had to be built around loops from the foundation.

The survey also showed clear hierarchy in what cyclists prioritize: scenery and safety were consistently the top two factors, well above surface type and distance. This held across casual riders, regular athletes, and touring cyclists. The insight was that scenery — something almost no existing tool addresses meaningfully — is not a nice-to-have for cyclists. It is often the reason they ride.

The nine in-depth interviews added texture to the numbers. Friction points clustered around three moments: before the ride (uncertainty about route quality, gradient, and conditions), during planning (inability to compare routes on the dimensions that actually matter), and route switching (the inability to quickly see how a different intent would change the output without reconfiguring everything from scratch).

We explored three directions. The first was adventure-driven routing — routes selected based on novelty, unexplored territory, discovery. The second was safety-first — routes that explicitly minimize traffic exposure, avoid main roads, and prioritize protected infrastructure. The third was inspiration-driven — routes curated by community input, editorial selection, or social signals.

All three had appeal. None of them alone captured the dimension that our research consistently surfaced: the ride intent that changes day to day. The same cyclist wants a challenging mountain loop on Saturday and a flat scenic loop after work on Tuesday. A system built around a single persona or a single intent cannot serve them both.

Route profiles emerged as the strongest answer. A profile is not a set of filters. It is a named intent — Scenic, Safe, Challenging, Balanced — that maps to a specific combination of weighted signals, routing constraints, and avoidance criteria. Switching profiles does not reconfigure a form. It generates a different route from a different premise. The cognitive load stays low. The output stays meaningfully different.

The key tradeoff we made deliberately: explainability over sophistication. We could have built an opaque scoring system that processed dozens of signals and produced a ranked list. We chose not to. If a rider cannot understand why the app recommended this route, they will not trust it on an unfamiliar ride. The signals we used — shade at a given time, surface type per segment, gradient tier, wind direction — are ones a cyclist can verify. That verifiability is the trust mechanism.

A route profile is a specification. When a rider selects "Scenic," odo translates that intent into a set of weighted API parameters: maximize shade coverage, prioritize unpaved surface where available, minimize main road exposure, optimize for continuous elevation change rather than flat terrain. These parameters are sent to OpenRouteService, which generates candidate routes against the constraints.

The raw routing output is then enriched. Shademap processes the route geometry against the current time and date to calculate actual shade coverage — not estimated, but computed from topographic and building data. Elevation data is processed to produce gradient metrics per segment, categorized into four tiers that match how cyclists actually think about climbs. Surface type is extracted from OpenStreetMap data via OpenRouteService and mapped to intelligible labels: paved, gravel, compacted dirt, technical trail.

Wind is the most behaviorally interesting signal. Cyclists care about wind direction relative to their route, not absolute wind speed. A strong tailwind on the outbound leg and a headwind on the return is a very different experience than the reverse. odo processes wind direction and route geometry together to produce a per-segment visualization: green above the axis for tailwind assistance, red below for headwind resistance. A rider can see, before starting, which sections will feel easy and which will be hard.

The output of all this processing is not a score. It is a set of labeled, segmented data that the interface displays in plain terms. The system is explaining itself continuously — not as a disclaimer, but as the product.

When the rider opens the app, they're greeted with three route profiles — each with one loop route, each built around a different set of metrics. Every day, each profile regenerates a fresh route against current conditions. Three profiles, three meaningfully different rides every morning. For the commuter cyclist with five minutes to decide, this is the flow.

Custom Ride offers full preference control. Onboarding in this flow captures rider type, bike type, specific preferences and avoidances, a time window, and a starting point. From these inputs, odo generates profiles and allows deep comparison before committing. For a cyclist planning a long weekend route in an unfamiliar region, this is the flow.

The functional prototype validated both flows using live API calls. We were not mocking data or using placeholder responses. Routes were generated from real OpenRouteService queries. Shade coverage was computed by Shademap against real topographic data for the query time. The prototype behaved as a real product would — including edge cases where API constraints produced unexpected route geometries that we had to design around.

This was the most important form of validation: the pipeline works with real signals, in real places, with real environmental variation. The concept is not theoretical.

In the plan phase, the rider selects a profile and reviews the route in detail before starting. The detail view presents the key metrics a cyclist uses to make the go/no-go decision: difficulty rating, total distance, elevation gain, estimated duration, and start time. The preview divides the route into segments with per-segment data — weather, surface, gradient — and highlights each segment on the map as the rider scrolls.

The navigate phase is designed for bike computer handoff. odo is a planning tool, not a turn-by-turn navigation tool — a deliberate scope decision. Cyclists navigate with dedicated devices. odo generates the route; the device runs the ride. This keeps odo focused on what it does well and avoids competing with the hardware category where Garmin and Wahoo have deep advantages.

The feedback phase is the long-term value driver. Post-ride, the rider can rate segments and adjust preferences. Over time, the profile learns — not through opaque machine learning, but through explicit preference signals that the rider understands and controls. A rider who consistently rates gravel sections poorly will see those sections appear less in future scenic routes. The system shows its reasoning at every step, including in how it updates.

Environmental signals — shade at a given time, surface type per segment, gradient per section, wind direction relative to route geometry — can be sourced from existing APIs, processed without proprietary data, and translated into labels that feel trustworthy in a planning context.

This matters because the core claim of odo is not "we designed a nicer route planner." It is "we proved that intent-based routing is possible with available data, at consumer scale, without requiring a proprietary data moat." The competitive differentiation is the architecture, not the visual design.

This pushed us toward explainability as a design principle, not just a feature. Every signal the system uses is visible. Every label is defined. Every recommendation comes with the reasoning behind it. This made the product harder to build — it is technically easier to produce an opaque score — but meaningfully more trustworthy.

The second reflection is about scope. We made a deliberate decision to build a vertical slice rather than a broad prototype. One city, four profiles, two flows — but with real data, real APIs, and real edge cases. That depth of validation is more useful than a wide prototype that fakes its data.