Freight Management Platform

Sanitised and conceptual. This describes the shape of the problem and the engineering approach in generalised terms. It is not a representation of any employer’s proprietary architecture, source code, data or internal metrics.

Context#

Freight software has an unusual property: the system it models is physical and already running. The trucks move whether or not your service is up. At Truckka Logistics I was Lead Full-Stack Engineer, and I architected and developed a full-fledged freight management system in Laravel with a companion mobile application in Kotlin.

This was the step from leading a stack to owning a system, and the first place the work was genuinely distributed rather than merely multi-tier.

The engineering problem#

Most web applications are request-driven: something happens because a user asked for it. Logistics is the opposite. The interesting events arrive unbidden and continuously: position updates, status changes, telemetry from vehicles. The system's value is in what it does with them.

That inverts the design. I integrated third-party tracking APIs and IoT logistics data to support dynamic delivery routing, which means the platform had to treat external feeds as a primary input rather than a dashboard garnish, and had to produce routing decisions that could change while a journey was already in progress.

What I owned#

• Architected and developed the freight management system in Laravel, the operational core of the platform.
• Built the companion mobile application in Kotlin for the field side of the operation.
• Integrated third-party tracking APIs and IoT logistics data to support dynamic delivery routing.
• Led agile-based iterations, driving continuous improvement from customer feedback and business requirements.

Conceptual architecture#

Freight management, conceptual data flow

1. Sources

   • Driver applicationKotlin · Android
   • Third-party trackingProvider APIs
   • IoT telemetryVehicle signals
   Ingestion

2. Processing

   • NormalisationOne event shape
   • Position & statusCurrent state
   Decisions

3. Platform

   • Freight managementLaravel
   • Dynamic routingRoute adjustment
   Surfaces

4. Consumers

   • Operations consoleDispatch
   • Customer visibilityDelivery status

Engineering considerations in telemetry-driven systems#

Ingestion and decision-making are separate concerns. Normalising many feed formats into one internal event shape, before anything makes a routing decision, is what stops provider-specific quirks from leaking into business logic, and what makes swapping or adding a tracking provider a contained change.

Signal loss is a normal condition, not an error. A vehicle in a coverage gap has not disappeared; it has stopped reporting. Systems that conflate those two produce alarming dashboards and untrustworthy routing. The state model needs "last known, as of" as a first-class concept.

The mobile client is a partially-connected node. A driver application is offline regularly and by design. It has to queue, tolerate delayed delivery, and reconcile when connectivity returns, which is a distributed-systems problem wearing a mobile-app costume.

Routing is a decision under uncertainty. Dynamic routing is only as good as the freshness and trustworthiness of the inputs behind it. Being explicit about how stale a signal is allowed to be before it stops influencing a decision is a design choice worth making deliberately.