How I ended up building this
The logistics industry has always been a pretty interesting one to me. It’s among the biggest in the world, as well as one of the most necessary to fulfill our needs, all across Maslow’s hierarchy of them. I have worked closely with a forwarding agency, based in Rotterdam, for a couple of years. Through them, I have come to learn about all the processes, challenges and problems that exist in the current world of logistics. I’ve been attacking the problem of inefficient logistics mechanisms from many angles, driven by my own interest. This course felt like the perfect moment to bring one of these angles “to life”. Naturally, I was happy that my teammates agreed to work on a so-called “empty miles solution”: one that aims to reduce the bizarre statistic of about 21.6% of EU road-freight kilometres being driven “empty”, meaning there’s no cargo on board in the container of a truck, just air. My teammates agreeing to this idea was my first indication that the idea was worth exploring, which got me thinking in ways to solve this massive problem for this massive industry.
From idea to working prototype
Since the idea originated with me, I felt like it was my duty to take most of the initial design and features into my own hands. I’ve built many (business) applications before with Claude Code, so building a prototype didn’t sound like anything new to me. What did surprise me, is the complexity caused by the number of interconnected decisions that overlap and rely on each other.
The basic concept sounds straightforward: take an empty container and use it for another shipment instead of sending it back to a depot. But then you have to consider container compatibility (which carries MANY variables), release times, carrier permissions, depot rules and whether a newly calculated route actually saves companies money in the end. I also came to realise that my domain knowledge alone didn’t bring me to a useful answer to the problem we’d identified. Knowing that empty running is inefficient, and even understanding the cause, is a long way from knowing which empty containers can realistically be reused, who needs to share information, who has permission to approve the move and who actually benefits. Finding nearby containers won’t be the hardest of challenges, but getting this entire system to work for everyone to save a couple of hundred euros per shipment is a massive ladder to climb.
With my dear friend Claude Code by my side, it was not speed that I needed. It was a clear feeling of direction, and a sharp view ahead of what this prototype had to do, and what it had to look like. To do that effectively, I had to make decisions on which features did deserve a spot in our v1, and which didn’t
Doing the math
After having randomly generated mock data to test our reasoning models against (to measure efficiency and accuracy of our solution’s inherent models), a big finding was that this business model can “make or break” depending on container suppliers’ reuse fees. Depending on how high these are in real scenarios, potential savings for forwarders can shrink from a couple of hundred euros to not much more than an average kapsalon nowadays. Some might still find that worth the try, but a company won’t switch up dispatching processes for savings like that.
A nicer surprise, however, was the fact that the model I had configured to extract information from mock data, had a 100% accuracy rate (against a baseline of 28.9% by code-run scripts) on 45 fictional booking emails. An important moment, since I wouldn’t have been proud to demo a prototype that can’t even deliver the result I was excited to pitch about.
Being aware of these challenging factors hanging over our head, it was important to add nuances to our demo. While pitching this as a potential weekly 5-figure saver for the Randstad forwarding area, it was important to note that industry adoption on a large scale is the crucial factor to pull this off, which is exactly the factor you can’t expect to work in your favour all the time in logistics.
Making the demo speak for itself
At first, I had built a very practical prototype that performed all the necessary features, but in a way that wasn’t self-explanatory even to myself. I caught myself staring at my laptop thinking; what on earth am I even looking at? I decided that for a nice-looking prototype, you need the visual appeal to speak even more to your audience than the functionalities of your platform. At the same time, you don’t want a malfunctioning application, so it’s a game of finding the ultimate balance between visual appeal and functionalities to make sure your audience actually gets your solution. A concrete example of how I did this was to use the infamous “less is more” principles, especially when we’re talking about text: no need for 6 bullet points that no one is interested in reading, I’d rather have 1-2 catchy headlines that spark people’s attention, so I can clarify what we mean by that while demonstrating the rest of our prototype.
Working as a team, not just building my part
Even though I was mainly responsible for the build of our prototype, collaborating and brainstorming with my teammates was a crucial part of the process to narrow down on what we exactly wanted to achieve and make happen with this project. It wasn’t too hard for us to find our way through the challenges and questions we faced during this project, but I’m convinced that having 3 other people with semi-different backgrounds to work with on a project is way more than the fourfold of efficiency you can reach in a group. Different insights and perspectives bring ideas, angles and feedback (both positive and negative) to the table that no AI assistant, let alone yourself, can truly offer.
What I’d do differently next time
Although I am very satisfied with the way this project went, there are a couple of things I would’ve done differently. Firstly, I’d say I’d narrow down from the beginning on the exact end goal of a certain prototype. In this case, functionality was definitely a high priority, but in the end, the only interaction people would have with it would be on a demo day. Hence, I could’ve taken into account earlier that it should be more of a “pitchy” demo, rather than a full-on logistics software solution.
Secondly, this project has reminded me of the importance of having feedback from other people, especially those with different perspectives and backgrounds. Your idea and solution might be self-explanatory to yourself (except for those confusing moments I explained above), but it requires a whole different approach to make others understand what you’re trying to achieve.
Empty kilometres are definitely a massive inefficiency that, in some ideal world, could be saved with a clever tool. After working through this project, I still believe that. However, I have become a tad skeptical about the easiness of solving it, for two intertwined reasons: first of all, why has no one else been solving it on such a scale? I believe it has to do with the second reason, which is something I touched upon lightly earlier: industry adoption is not a given in logistics. For hundreds of forwarders to share sensitive information to save money, you better save them quite some. Hence, I am not dropping this project, and will continue to research this (and other) angles to make sure we all cut a bit of CO2-emissions, driver costs and fuel costs in order to keep our overconsumption in the happy place we have it in in these days.
