Cold chain monitoring, reporting and alerting, built at speed

Context

Temperature-controlled freight is unforgiving. A refrigerated consignment that drifts outside its range is not a delayed delivery. It is a destroyed one, and depending on the cargo it can be a compliance failure as well as a commercial loss. Pharmaceutical, pathology and food consignments all carry obligations about the conditions they were transported in, and the burden of proof sits with the carrier.

The practical difficulty is that the information needed to prevent a loss and the information needed to prove compliance afterwards are the same information, but they have to arrive at very different speeds. A monthly report satisfies an auditor. It does nothing for a driver who could have moved a consignment two hours ago.

Direct Couriers needed all three: continuous monitoring across the fleet, reporting solid enough for customers and auditors, and alerting fast enough to actually change an outcome.

Our approach

Alerting designed around what someone can do

The first design conversation was not about sensors or thresholds. It was about what actually happens when an alert fires: who receives it, what they can do at that moment, and how long they have.

That framing changes the system. An alert that fires the instant a reading crosses a threshold produces noise, because readings fluctuate for benign reasons every time a door opens. An alert that waits for certainty produces confidence and arrives too late. The useful design sits between the two, and finding it is a question about operations rather than about software.

Reporting that serves the audit as well as the day

Monitoring data is only worth collecting if it can be produced later in a form somebody will accept. We built the reporting layer alongside the live monitoring rather than after it, so the same record that drives an alert today supports a compliance question in six months.

Built with AI-accelerated development practices

This is how we work now across every commercial engagement.

We use AI development tooling heavily in our own delivery: for scaffolding, for the unglamorous integration code, for test coverage, and for the repetitive work that historically consumes the majority of a build. Used carelessly that produces a large volume of code nobody understands. Used deliberately, with an engineer reviewing every change and a test suite that has to pass, it compresses timelines substantially.

The effect is not that we write the same system faster. It is that the cost of trying an approach drops far enough that we can build two and discard one, which produces a better system than committing early to the first design that seemed plausible.

Handed over to be operated

The system runs in Direct Couriers' environment, and the team holds the code, the infrastructure definition and the documentation. We are not a dependency for its day-to-day operation.

Outcomes

Direct Couriers now has continuous visibility over temperature-controlled freight, with alerting that reaches a person while a load can still be recovered, and reporting that answers a customer or auditor from the same record.

The build took weeks rather than quarters. That mattered beyond cost: the system met real freight while the problem was still fresh, and we adjusted it before early assumptions hardened into architecture.