The Moment the GPS Said 'No' — and What It Taught Me About AI and Logistics
While building Arise & Shine Transporters, a logistics platform for sand and aggregate delivery in Kenya, I hit a roadblock with GPS telemetry. Through collaboration with Claude and Codex, I found a solution that changed how the platform handles real-world data.
"The Moment the GPS Said 'No' — and What It Taught Me About AI and Logistics While building Arise & Shine Transporters, a logistics platform for sand and aggregate delivery in Kenya, I hit a roadblock with GPS telemetry. Through collaboration with Claude and Codex, I found a solution that changed how the platform handles real-world data. It was mid-morning on a Tuesday, and I was deep in the process of integrating real-time GPS tracking into Arise & Shine Transporters. The goal was simple: to allow the platform’s admin to see exactly where each truck was at any given moment. But something was wrong. The GPS data was inconsistent. Some trucks showed up in the wrong location, and others didn’t appear at all. It was frustrating. I had followed the API documentation carefully, and yet the system wasn’t behaving as expected.
I turned to Claude for help. I described the issue in detail — the GPS coordinates were coming in, but they didn’t match the actual truck locations. I even shared a sample of the data. Claude asked pointed questions: Was the GPS hardware working correctly? Were the APIs being called at the right intervals? Had I accounted for time zone differences?
Claude’s suggestions were practical. It pointed out that the GPS data might be coming in with a delay, and that the platform needed a way to buffer and verify the data before displaying it. It also suggested looking into the API’s polling interval — the system was set to poll every 60 seconds, but the GPS hardware might be sending updates more frequently. That could lead to data being lost or misaligned.
I tried adjusting the polling interval to 30 seconds, and also added a small buffer in the backend to hold incoming GPS data until it could be verified. But even then, the data wasn’t lining up perfectly. I was starting to doubt whether the GPS hardware was compatible with the APIs I was using.
That’s when Codex came in. I shared the code with Codex and asked for help debugging it. Codex quickly identified the root of the problem: the GPS coordinates were being received in a different coordinate system than the one used by the platform. The GPS data was in WGS84, but the platform was using a local coordinate system. That’s why the locations didn’t match.
Codex suggested a simple fix: convert the incoming GPS data from WGS84 to the local coordinate system before displaying it. I implemented the conversion, and suddenly everything started working as expected. The map showed the correct locations for each truck, and the admin could now track their movements in real time.
This moment was a turning point. It wasn’t just about fixing a bug — it was about understanding the nuances of real-world data. GPS isn’t perfect. It can be delayed, inaccurate, or misaligned. Building a system that works in the real world requires more than just following documentation — it requires listening to the data and being open to unexpected solutions.
Working with Claude and Codex didn’t just help me solve the problem — it taught me how to think about it differently. I learned to ask better questions, to look for patterns I might have missed, and to trust the process of discovery, even when it didn’t go as planned.
Now, when I look at the map in Arise & Shine Transporters and see trucks moving exactly where they
