Dispatch

Dispatch rethinks how we move, combining travel time with real-world delays to tell you when to leave, reducing stress and improving coordination across cities, campuses, and shared systems.

Comment

Inspiration

Dispatch came from a simple but frustrating problem. People often leave too early and waste time waiting, or leave too late and arrive stressed. Most travel tools only calculate drive time, but they ignore the real-world delays that actually shape how we move through shared spaces like cities, campuses, workplaces, and event venues. Things like parking, crowds, congestion, and wait times are left for the user to figure out.

We wanted to build something that answers the question people actually care about: “What time should I walk out the door?” Dispatch takes those real-world factors and turns them into one clear, reliable decision.

What it does

Dispatch calculates the best time to leave by combining travel time with real-world delays. Instead of just showing how long a trip takes, it provides a clear “leave by” recommendation based on traffic, timing data, estimated waits, and buffers.

It can be used across different scenarios like airport travel, events, school pickup, and daily routines. The goal is to reduce stress, minimize wasted time, and make planning more predictable.

How we built it

Dispatch is a full-stack application built with a React and Vite frontend and a Flask backend. The frontend handles the user experience, while the backend processes routing, timing data, and delay estimation.

We used OpenRouteService for drive times and AviationStack for flight timing. We also built a CBP scraper with caching to collect and reuse airport wait-time data. These inputs are combined through a calculation engine that produces a final leave-time recommendation.

Challenges we ran into

One of the biggest challenges was coordinating a system with multiple moving parts. With a frontend, backend, APIs, and different responsibilities, making sure everything worked together required strong communication and alignment.

Another challenge was integration. Even when individual components worked, combining them into one system without breaking functionality took careful iteration.

We also had to shift into a user mindset. While the system worked technically, using it as a real user revealed missing flows and expectations that were not obvious during development.

Accomplishments that we're proud of

We’re especially proud of building the CBP scraper and caching system. It allowed us to collect airport wait-time data and reuse it, making the system more realistic and adding a unique technical component.

We also focused on creating a cohesive product experience. From the landing page to the dashboard, Dispatch feels consistent and intentional, making it feel more like a real product rather than just a prototype.

What we learned

We learned that real-world timing is much more complex than it seems. It’s not just about the route, but everything surrounding it, including delays, uncertainty, and incomplete information.

We also learned how important it is to handle unreliable data. APIs don’t always behave consistently, so building fallback systems and handling edge cases was essential.

Most importantly, we learned to think from a user’s perspective. Something that works technically isn’t always enough—it also has to feel complete and intuitive to use.

What's next for Dispatch

Dispatch is designed to grow into a general “when should I leave” system.

Next steps include adding confidence scoring to show how reliable a recommendation is and learning from user outcomes to improve accuracy over time. We also plan to move trip history and accounts into a backend system to support saved trips, recurring routines, and cross-device use.

Long term, Dispatch can expand into broader use cases like commuting, events, and campus coordination, helping improve how people plan and move through shared spaces.

Built With

Share this project:

Updates