Operations platform for a freight and logistics group

The situation

Three systems had grown up separately: a legacy scheduling tool, a spreadsheet-driven depot handover process, and a customer-facing tracking page fed by a nightly export. Each was individually defensible and collectively unworkable. The same shipment existed in three states, and reconciling them was somebody's morning.

The brief we were given was to rebuild the scheduling tool. The brief we agreed, after discovery, was to consolidate all three — because rebuilding one of them would have left the reconciliation problem exactly where it was.

What we built

A single operations platform with one authoritative record per shipment, and views composed on top of it for each role: depot staff, dispatch, account management, and the customer-facing tracking page. Nothing is exported and re-imported; the tracking page reads the same record the depot updates.

• One shipment record as the single source of truth, replacing three partial copies
• Role-based views built on that record rather than separate applications
• Live state propagated to the customer tracking page, removing the nightly export
• Infrastructure as code with a deployment pipeline the in-house team now runs

How it was delivered

We shipped a working vertical slice in the first fortnight — one shipment type, moving through the real pipeline, visible to a real depot. It surfaced an integration assumption that was wrong, early enough that correcting it cost days rather than months. The rest of the build followed the approach described in scope that holds.

The platform runs on cloud infrastructure we set up as code, and the client's own engineers took over deployments before we finished.