Dispatch looks simple from the outside: passengers book rides, drivers pick them up, vehicles go to the airport. The reality is a continuously shifting logistics puzzle, one we grew up watching our families solve every single morning.
A van just broke down on the side of the highway.
Six passengers on board. Two have international flights in a few hours. Click each decision the dispatcher must make right now.
Both of us at ReThread grew up around that reality. Moaz's family ran a nonemergency medical transportation (NEMT) business. Ahmad's family ran airport shuttle operations. Different models, different customers. The same underlying challenge, though: coordinating vehicles, drivers, passengers, and time.
We saw the early morning calls. The scrambling when flights changed. The pressure that dispatchers carried every day trying to keep everything moving.
We're not claiming to be experts in this space. But we grew up watching it closely, and recently we've started studying it more intentionally as we design software for transportation operators.
The deeper we look, the more one thing becomes clear: dispatch is a far more complex problem than it appears from the outside.
The Reality of Dispatch
On paper, an airport shuttle operation sounds simple. In reality, dispatch is a constantly shifting logistics puzzle.
A delayed flight may push a pickup window. A late passenger may force route changes. A vehicle issue may require reshuffling an entire manifest.
Dispatchers are constantly balancing these variables in real time, often with incomplete information and limited time to react. And in many companies, a large part of that coordination still lives entirely in the dispatcher's head.
Where Operations Struggle
Through conversations with operators and observing how these businesses run, a few common pressure points appear repeatedly. These are not failures. They are simply the natural friction points of a complicated operation.
One of the most complex parts of dispatch is grouping passengers into shared trips. It requires understanding geography, pickup timing, traffic patterns, flight schedules, and vehicle capacity. All of these, simultaneously.
In many companies, one or two experienced dispatchers develop an intuition for how to do this efficiently. The risk: this operational knowledge lives with specific individuals. If that person leaves, the company can suddenly lose a significant portion of its logistical expertise.
Most transportation platforms today include some form of flight tracking, and that is helpful. But often the system simply updates the flight status.
The operational decisions that follow still fall to the dispatcher: Should pickup times be adjusted? Should passengers be regrouped? Should drivers be rerouted? The system provides information, but the dispatcher must still translate that information into action.
In many companies, driver communication still relies heavily on phone calls, text messages, and dispatcher relays. Any technology that attempts to improve this has to respect a fundamental constraint: drivers are operating vehicles.
They cannot safely interact with complicated software while driving. That means any system designed for drivers must be built around real driving conditions. This is why we believe the only way to design it correctly is to ride along with drivers and observe how they actually work.
The Transportation Software Landscape
There are already many software tools used across the transportation industry. Broadly speaking, they fall into a few categories.
Reservation Focused
Tools that help companies accept reservations online and manage scheduling. Strong for booking and payment, but often provide limited operational support once the day of service begins.
Operational Dispatch Platforms
Systems built specifically around dispatch and operations, including Hudson, Santa Cruz, and LimoAnywhere. Powerful and used by many established operators, but often reflecting operational models from many years ago. Can be complex or expensive for smaller operators.
Emerging Opportunity
Cloud infrastructure, mapping services, and modern APIs have made route optimization, real time data integration, and automated trip creation far more accessible than even a decade ago. Could smaller operators now have access to capabilities previously only large companies could afford?
The Four Principles We're Designing Around
As we study this space and experiment with building new systems, a few core principles keep coming up. These principles guide how we think about transportation software.
What We're Learning About Good Systems
The deeper we explore this space, the more we believe good operational systems share a few characteristics.
Why This Matters for Small Businesses
For transportation companies, operational systems have a direct impact on the health of the business.
Profitability
Efficient routing and scheduling can significantly affect margins on every trip. Wasted miles compound over thousands of trips.
Customer Experience
Clear communication and reliable service drive repeat bookings. New customers become regulars when they feel informed and valued.
Employee Stress
Better systems reduce the pressure placed on dispatchers and drivers. Lower burnout means lower turnover, a very real cost for any small operation.
Long Term Competitiveness
As traveler expectations evolve, companies that cannot modernize their operations may struggle to keep up with operators who can.
Why We're Studying This
This exploration started with something simple: both of us grew up watching our families run transportation businesses.
We saw the pressure behind the scenes: the early mornings, the sudden changes, the constant effort to keep everything moving smoothly.
Now we're trying to understand those systems more deeply. Not just to build software, but to understand how modern tools might make these operations easier to run.
The complexity of transportation dispatch has already given us a deep respect for the people who manage it every day. And that's where this work begins.
We're still learning. But we believe that respect for the problem, built from years of watching it up close, is a better starting point than most.