RideFlow

Small local transport operators coordinate rides over phone calls and spreadsheets. There is no shared view of where drivers are, which rides are unassigned, or how long a trip should actually take — so dispatchers guess, and riders wait without information.

I built a single platform with three surfaces on one data model: a rider app for booking and live trip tracking, a driver view for accepting and completing rides, and an operations dashboard for dispatchers. Driver positions stream through Firebase so every surface reflects the same state within a second, and the Google Maps Directions API generates optimized routes and honest arrival estimates instead of flat guesses.

The hard call was how to move location data. Polling a REST endpoint was simple but produced stale positions and hammered the API; a full WebSocket layer meant running and scaling stateful infrastructure I did not need elsewhere. I split the concerns instead — Firebase Realtime Database carries the high-frequency position stream, while all durable state (users, rides, pricing, history) stays in MongoDB behind the Node API. Live data stays live, the source of truth stays relational, and neither side is doing the other one’s job.

Dispatchers see every active trip on one map, riders get arrival estimates grounded in real route data, and role-based auth keeps rider, driver, and admin capabilities cleanly separated. The split data model turned out to be the piece that made the rest simple.