Dispatch and freight platform

A trucking company runs on a chain of handoffs. A load shows up on a load board. Someone bids on it. If the bid wins, a dispatcher assigns a truck, the driver picks up and delivers, the customer gets an invoice and the driver gets paid for the week. When each step lives in a different tool, every handoff is a place for a load to get lost or a number to be typed twice.

The company already had its own system covering that whole chain. Our job was to work inside it: add what was missing, rebuild the parts that had stopped keeping up, and keep it fast while the operations team used it all day.

• Loads in. Postings arrive from several load boards, each in its own format, along with rate confirmations that come as PDFs. Every source has its own parser, so a problem with one board stays with that board.
• Dispatch and trip monitoring. Dispatchers see every active trip sorted by what needs attention: on time, running late, or needs action. A truck that has stopped reporting its position moves to needs action. It does not keep a confident arrival time worked out from an old position.
• Billing and driver pay. Invoices, rate confirmations and weekly driver settlements are generated from the same load record, so what the customer is billed and what the driver is paid start from one place.
• Realtime. Messages, load updates and notifications reach dispatchers' screens and drivers' phones over WebSockets.

Replacing things while people are using them. Two examples.

Realtime ran on a hosted service, and we moved it to a server the company runs itself. For a while every message was published to both, with a few test users reading from the new server and everyone else still on the old one. The switch happened only once every driver's phone was on an app version that could follow it. Before that we load-tested the new server with 2,000 open connections, and 95% of messages arrived within 272 milliseconds.

Driver pay is the second. A settlement that gets regenerated must not quietly change what a driver was already paid. The fix we designed is a journal that only ever adds entries: every correction is its own line with a reason, and any difference between what was paid and what the system now calculates lands in a review queue.

In daily use. The operations team works in it from the first load of the morning to the last delivery at night, and the driver app and the safety scoring in the other case studies run on top of it.