About the Project

What inspired us

What really inspired us was the actual problem behind the Trucker Path challenge. The more we looked at it, and especially after talking with the sponsor, the more we understood that small trucking fleets are still doing way too much manually. Dispatchers are checking on drivers through calls and texts, looking at different screens, trying to remember who is free, who has enough HOS left, which load makes sense, and where money is being lost. That whole process felt outdated, stressful, and honestly kind of surprising for such an important industry.

That is where our idea came from. We did not want to make just another dashboard with a lot of data on it. We wanted to build something that could actually help a dispatcher make a decision. That is how Co-Dispatch started. We saw that Trucker Path already has a lot of the inputs, like tracking, trips, and fleet information, so our thought was, what if we build the missing layer that actually turns all of that into useful actions?

What we built

We built Co-Dispatch, which is basically an AI co-pilot for small-fleet dispatchers. The main goal was to make dispatching feel less manual and less chaotic. Instead of the dispatcher having to figure everything out from memory or by messaging drivers one by one, the system helps with the next action right away.

Our project has four main workflows. First, it gives a morning fleet snapshot so the dispatcher can quickly see who is ready to run. Second, it does driver ranking for a load using actual factors like deadhead, HOS, ETA, and cost. Third, it finds backhaul opportunities, so instead of sending a truck back empty, it can try to match a return load. Fourth, it supports proactive monitoring, where the system can detect a problem on the road and respond with an alert and even a voice intervention flow.

How we built it

We built the project using Next.js 14, TypeScript, Prisma, SQLite, Tailwind CSS, and Mapbox GL. For the intelligence side, we used LLMs through Groq and Gemini, but one thing we were careful about was not letting the AI do everything blindly. The actual scoring and dispatch logic were still based on real math and rules, while the LLM was mainly used for parsing, explanation, and making the system feel more natural to use.

For the trucking side, we designed the app around the NavPro / Trucker Path style workflow, which gave us the driver, trip, and tracking side of things. One of the challenges, though, was that open broker load-board APIs are not really freely available in a clean way, so for the marketplace side we built a realistic seeded dataset of loads so that the product could still demonstrate live dispatch and backhaul logic in a believable way.

We also made sure that actions in the system were persisted, so things like assignments, interventions, and decisions were actually being stored instead of just appearing on the screen for show.

What we learned

One big thing we learned was that logistics is not just about moving trucks, it is really about decision-making under pressure. We came into this thinking a lot about AI and dashboards, but pretty quickly we realized the real value was not in showing more data. It was in reducing friction for the dispatcher.

We also learned how important domain knowledge is. Once we started understanding things like deadhead, backhaul, HOS, relay, and cost per mile, the project became much more real. Before that, it was easy to think about the problem too generally, but once we started thinking from the dispatcher’s side, everything became more focused.

Another thing we learned was that if we wanted this to feel trustworthy, the system had to be explainable. A dispatcher cannot just be told “pick this driver” with no reason. So we learned how to combine deterministic logic with AI explanation, which gave us something that felt both useful and believable.

Challenges we faced

One of the hardest parts was the data side. Real broker load listing APIs are mostly commercial, restricted, or hard to get access to quickly, so we had to work around that by creating our own realistic broker-load layer. That took more time than we expected, because we wanted it to feel close to the real trucking world and not obviously fake.

Another challenge was balancing AI with reliability. We did not want the project to become one of those demos where the model just says impressive things but the logic behind it is weak. So we had to make careful choices about what should be powered by actual scoring and what should be handled by the LLM.

We also had the challenge of turning a pretty large logistics problem into something that could be shown clearly in a short hackathon demo. In real life, dispatching is continuous and messy, while in a presentation everything has to feel quick, visual, and easy to understand. That took a lot of iteration.

And honestly, just coordinating everything was a challenge too. We were thinking about the product, the tech stack, the demo flow, the GTM angle, and the presentation all at the same time, so it really felt like building a startup in a very short amount of time.

Why this project matters to us

What made this project exciting for us was that it felt useful right away. Small fleets do not need more complicated software. They need something that saves time, reduces bad decisions, and protects their margins. Co-Dispatch tries to do that by helping dispatchers assign better, catch problems early, and recover value that would normally be lost through empty miles and missed backhauls.

In the end, this project was our way of showing that AI can be more than just a chatbot or summary tool. It can actually become part of a real operational workflow and help people make better decisions in industries where every hour and every mile matters.