Inspiration
Waypoint was inspired by the uncertainty behind everyday regional transit commutes. A trip can look simple on a map, but a delayed train, a missed transfer, an unreliable bus corridor, or a small arrival-time change can completely change when someone needs to leave.
I wanted to build a commute assistant that answers the practical question commuters actually ask: “When should I leave, and what should I do if the plan changes?” The project was also inspired by the opportunity to use AI in a way that is helpful and explainable without allowing a language model to invent transit facts.
What it does
Waypoint helps commuters plan a route between transit stops and decide when to leave. It provides:
- Departure recommendations based on the requested arrival time, route duration, and safety buffer.
- Primary and Plan B routes with risk, reliability, transfer, and feasibility information.
- Multimodal itineraries, including PATH, subway, LIRR, NJ Transit, buses, ferries, walking transfers, and driving.
- Route-specific fare estimates with source, effective date, confidence, and limitations.
- Replayable normal, delay, and reroute scenarios for consistent demos and testing.
- An AI commute copilot that explains route decisions and answers questions using the same grounded route and feed data.
- An AI product direction centered on frequent routes, proactive commute briefs, preference learning, and buffer-aware suggestions.
How I built it
Waypoint is a Next.js application with a React and Tailwind interface. The route engine is deterministic: it builds ordered route legs, transfer buffers, arrival feasibility, fare estimates, and risk scores from the selected stops and transit snapshot.
The AI layer uses NVIDIA Nemotron through Nebius Token Factory for explanations and conversational responses. The model receives structured route evidence and is constrained to cite only times and facts present in that evidence. If the model is unavailable or fails the grounding check, Waypoint falls back to a deterministic explanation.
The project also includes:
- Replay feed fixtures for normal, delayed, and rerouted service conditions.
- Optional live weather, traffic, transit, and agency-alert integrations.
- LangSmith tracing for lead-agent decisions.
- Tavily-based incident research in live mode.
- Tendem escalation support for low-confidence or feed-conflict cases.
- A Mapbox map with a deterministic visual fallback.
- Automated unit, type, build, and Playwright end-to-end tests.
Challenges I ran into
One of the biggest challenges was representing transit realistically instead of treating every station pair as a direct ride. For example, WTC to 33rd Street requires a PATH transfer at Journal Square, while a PATH-to-subway or LIRR-to-subway journey requires separate legs and transfer time. The route engine had to become network-aware enough to distinguish direct corridors from transfer journeys.
Fare estimation was another challenge. PATH and MTA fares can be represented with published values, but LIRR, NJ Transit, transfers, passes, peak periods, and payment methods require more context. Waypoint therefore exposes fare confidence and source information instead of presenting every estimate as exact.
It was also important to make the AI useful without making it authoritative over transit truth. Model responses can be fluent while still citing an invalid time, so the application validates model output and preserves the deterministic route engine as the source of truth.
Finally, building a reliable demo required replay mode. Live transit services can be unavailable, delayed, or difficult to reproduce, so replay fixtures make route behavior and test results repeatable while keeping a path open for live feeds.
Accomplishments that I'm proud of
- Built an explainable commute-planning experience rather than a generic chatbot.
- Added multimodal route legs and protected transfers for complex trips.
- Corrected agency labeling so LIRR routes are not incorrectly presented as PATH routes.
- Added route-specific fare breakdowns instead of one generic rail fare.
- Added current-time actions and a consistent time-picker interface.
- Created deterministic fallbacks for feeds, maps, fares, and AI reasoning.
- Added validation that prevents AI explanations from inventing route times.
- Covered the core experience with automated tests, including the WTC → 33rd transfer case.
What I learned
I learned that a strong AI product often starts with better structured data and clearer system boundaries, not with a larger prompt. The most reliable architecture is to let deterministic systems own route facts, timing, fares, and risk, while AI focuses on explanation, personalization, and conversation.
I also learned that uncertainty should be part of the product interface. Showing the source, confidence, effective date, and limitations of a fare or recommendation builds more trust than displaying a precise-looking number without context.
The project reinforced how important replayable scenarios, schema validation, and end-to-end tests are when combining external feeds, third-party APIs, and language models.
What's next for Waypoint
- Add a frequent-routes calendar for saved weekday commutes, recurring departure windows, and exceptions.
- Generate proactive pre-departure briefs when a delay materially changes the recommended plan.
- Learn editable commuter preferences such as fewer transfers, lower fare, accessibility, or higher arrival certainty.
- Connect official station-pair fare lookup services for more precise LIRR and NJ Transit pricing.
- Add accessibility-aware routing, elevator outage information, and step-free transfer guidance.
- Support natural-language route edits such as “leave ten minutes earlier,” “avoid ferries,” or “add a coffee stop if I have enough buffer.”
- Expand live transit coverage while preserving replay mode for reliable testing and demos.
Log in or sign up for Devpost to join the conversation.