`bestroute`: The routing engine that finds the cheaper commute hiding inside your ride-hail trip
Built for Malaysia's Klang Valley, this open-source app compares direct rides, pure transit, and hybrid routes, then ranks them by the trade-off that matters most: time or money.
- `bestroute` treats commuting like an arbitrage problem, searching for the cheapest practical version of a trip instead of assuming the fastest road trip is the best answer.
- Its real breakthrough is making mixed-mode travel a first-class route family, so ride-hail, rail, and walking compete inside one ranking system.
- The preference slider turns route selection into a live time-versus-cost negotiation, not a fixed shortest-path calculation.
- Local station data and fallback geocoding keep the app useful when external routing services are missing or unreliable.
The hidden cost of a daily commute
Most routing apps answer one question: what is the fastest way from A to B? `bestroute` asks a sharper one for commuters in the Klang Valley: what is the cheapest version of this trip that still makes sense? That shift matters because daily ride-hail spending can hide a simple arbitrage opportunity.
If a trip can be split into rail plus last-mile hops, the savings are not theoretical. The whole app is built around that premise: a route is not one path, it is a set of trade-offs waiting to be priced.
Why Klang Valley needs a local routing brain
`bestroute` is not trying to beat Google Maps at being universal. It is trying to be better at one place, one travel pattern, and one set of assumptions. That is why the repo hard-codes local station data, fare logic, and geocoding fallbacks instead of pretending a generic map stack can infer everything.
The local context matters. Stations, fares, and handoffs between e-hail and rail are not edge cases in Kuala Lumpur's commuter life. They are the entire point, which is why the code treats Malaysian transit data as a core dependency rather than a nice-to-have.
`bestroute` does not search one route. It searches five.
That is the core architectural move. Instead of asking an optimizer for a single answer, `bestroute` generates a small menu of route strategies and compares them side by side. The project's value comes from making mixed-mode travel legible enough to score, not from pretending every journey should be treated like a straight line.
| Route strategy | What it favors | When it wins | What it gives up |
|---|---|---|---|
| Direct e-hail | Speed and simplicity | When time matters more than cost | Usually the most expensive option |
| Pure transit | Lowest cash cost | When the user can tolerate transfers and waiting | Can be slower and less flexible |
| E-hail to transit | A cheap first mile | When parking, access, or feeder coverage is awkward | Still depends on a station handoff |
| Transit to e-hail | A cheap middle segment | When the destination is far from the nearest station | Adds a last-mile premium |
| Mixed e-hail plus transit plus e-hail | The best balance point | When the cheapest practical route is a stitched journey | More moving parts and more planning |
This is why the app feels different from a plain route finder. It is not choosing between roads. It is choosing between economic strategies for the same trip.
The slider is the product
In `src/lib/scoring.ts`, the preference slider is not decoration. It changes the weighting between cost and time after normalizing the candidate routes, so the ranking reflects what the user cares about right now rather than a universal definition of best.
Slide toward money and a slower route can win. Slide toward speed and the ranking flips. That makes the product feel like a negotiation instead of a verdict, which is exactly the right interaction for commuters trying to balance their budget against the clock.
The fallback system is the quiet superpower
The resilience layer is easy to miss, which is usually a sign that it is doing its job. If routing or geocoding APIs are unavailable, the app falls back to local station coordinates and distance estimates, so the experience degrades gracefully instead of failing outright.
That matters more than it sounds. For a local transport tool, API failure is not a rare bug. It is part of the operating environment, and `bestroute` treats it that way.
What it replaces, and what it really competes with
`bestroute` is not trying to be a better version of every map app. It is competing on a narrower axis: cost-aware mixed-mode planning for a specific commuter ecosystem. That makes it less universal than Google Maps, but more opinionated in the place where the user's pain is most concrete.
Against ride-hail apps, it asks a different question. Against transit planners, it asks a more practical one. It is not a feature checklist rival. It is a reminder that the best route tool is the one that understands the user's actual constraint.
A niche app with a broad lesson
`bestroute` looks narrow because it is designed for one city and one commuting problem. That narrowness is the point. Good software in constrained environments often wins by combining local data, graceful fallback, and a sharp opinion about what should be optimized.
In this case the opinion is blunt: the best route is the one that respects both your wallet and your clock. That is a small idea with a big product shape, and it is why this repo reads like a useful prototype instead of a generic demo.