01 / ContextThe question
behind the work.
Conventional map products can calculate a route, but they do not plan the human trip particularly well. They rarely explain fuel cadence, overnight choices, hotel practicality, or whether the proposed drive matches the traveler's preferences.
My role
I built the product end to end: responsive interface, server-side route orchestration, stop generation, hotel lookup, trip scoring, predictive fit, product instrumentation, session security, paid-API controls, exports, and deployment.
03 / In detailPlan the trip, not just the route
Wayline turns a long drive into a plan someone can actually use. The planner takes origin, destination, number of days, fuel cadence, route preference, and travel assumptions, then combines Google Routes and Places data into a day-by-day itinerary.
A completed run includes fuel stops, overnight cities, hotel options, map handoff, export files, and the reasoning behind the plan. The reference Las Vegas-to-Greensboro route covered 2,256 miles in 32 hours and 47 minutes across three driving days, with nine fuel stops and two overnight cities.
Make the score explain itself
I scored candidate stops using route position, detour cost, daily distance, hotel availability, and preference fit. The planner surfaces those tradeoffs so a traveler can see why a city or hotel was chosen instead of getting an unexplained recommendation.
The same trip state feeds a transparent quality score and a lightweight predictive-fit layer. The reference itinerary produced a 67 out of 100 quality score and an 86 percent predicted fit, alongside PDF, text, JSON, share-link, and Google Maps outputs.
Treat the planner like a product
Paid map APIs and product measurement shaped the backend. I kept route logic server-side and added email-gated sessions, CSRF checks, rate limits, Redis locks, quotas, and server-side keys around the planning flow.
The product tracks planner views, gate submissions, planning runs, quota blocks, result views, exports, and shares. That event layer gives future iterations a clean base for funnel analysis and trip-quality evaluation.
04 / Engineering judgmentThe decisions
that shaped it.
- Kept route and scoring logic on the server so paid credentials and business logic are not exposed in the browser.
- Used explainable stop scoring because a traveler needs to understand why a city or hotel made the itinerary.
- Instrumented the funnel before claiming product success: planner views, gate submissions, runs, quota blocks, results, exports, and shares are structured events.
- Treated the predictive layer as lightweight guidance rather than overstating it as a mature recommendation model.
Evaluation & results
The reference Las Vegas-to-Greensboro run produced a 2,256-mile plan, 32 hours 47 minutes of driving, three driving days, nine fuel stops, two overnight cities, a 67/100 quality score, and an 86% predicted fit. Every output format was generated from the same trip state.