CabVector

CabVector: turning transit disruptions into safe, proactive taxi staging across New York City.

Comment

CabVector: Project Story

Inspiration

Have you ever been stranded when an NYC subway line suddenly goes down? It’s pure chaos. Hundreds of frustrated people pour out onto the street looking for a ride, while nearby roads instantly gridlock. We wanted to solve this dual problem: how can we proactively guide taxis toward stranded passengers without turning the surrounding streets into a parking lot? That question sparked the idea for CabVector.

How We Built It

We built CabVector from the ground up as a full-stack web application:

  • The Brain (Backend): We used FastAPI to handle the state management, scoring logic, safety workflows, and live API endpoints.
  • The Interface (Frontend): Next.js powers our multi-page interactive dashboard.
  • The Map: Leaflet and CARTO tiles bring the data to life, visualizing the disruptions, map legends, and staging zones.
  • The Integrations: We built hooks for MTA, NYC DOT, OpenAI, and Groq APIs.

Knowing that live demos can be risky, we engineered dependable fixture data so the app runs flawlessly even without API keys. The entire system is governed by a strict, deterministic workflow:

$$ \text{Fleet proposal} \rightarrow \text{Traffic validation} \rightarrow \text{Approved dispatch} $$

A taxi's state doesn't change until it passes through every single checkpoint. A dispatch is only approved if it makes sense for both the driver's wallet and the city's traffic grid:

$$ (L\text{-Score} > 70) \land (\text{Congestion Index} \leq 0.7) $$

Challenges We Ran Into

If you've ever worked with live public city data, you know the struggle. Transit and traffic feeds are notoriously flaky—authentication methods change, responses lag, and connections drop out of nowhere. Instead of letting the app break, we engineered resilient fallback mechanisms and live health indicators. If a provider goes down, the dashboard stays functional and is completely transparent about what data is missing.

Another massive headache was keeping everything perfectly in sync. Ensuring the map, fleet state, alerts, and backend decisions were all telling the same story required us to nail down clear shared contracts and rely heavily on server-sent events.

What We Learned

This project was a masterclass in building operational AI. We learned that these systems absolutely need reliable fallbacks, transparent rules, and a hard wall between an AI's "suggestion" and a system's "action."

On the technical side, we leveled up our skills in real-time state synchronization, map visualizations, and collaborative full-stack architecture. We also had a great time using Codex (powered by GPT-5.6) as an engineering copilot. It was incredibly helpful for untangling integration bugs and organizing our implementation phases, proving its worth as a collaborator rather than a runtime dispatch engine.

Built With

Share this project:

Updates