Case Study

Logistics dispatch platform

The system that runs outbound logistics for a multi-division building-materials group in Ireland and the UK. It sits between the group’s ERP and everyone who moves its goods: dispatchers, hauliers and their drivers, pickers loading in the yard, merchants waiting on delivery. I built and extended it as the senior engineer, white-label through a partner agency.

Anonymized under NDA: the product appears here as “Meridian”, with fictional customers and hauliers.

Laravel 12PHP 8.3+MySQLBladeVue 3Bootstrap 5Laravel PassportDynamics 365 Business CentralAzure Blob StoragePusherBitbucket CI

The problem

Orders live in the ERP, but the goods are moved by third-party hauliers, loaded by pickers in the yard, and received by merchants who each want to know where their order is. Nothing joined those parties, and the ERP link ran over a legacy mainframe swapping CSV files by FTP. The brief: one place where a delivery is planned, dispatched, proven, and invoiced.

meridian · /insights

Operations dashboard with order and load counters, haulier and driver status chips, latest deliveries, and a haulier-acceptance panel with expiry countdowns.
[fig. 1] Ops dashboard: current stats, haulier and own-driver status, latest deliveries, and haulier acceptance with expiry countdowns.

What I built

A central logistics hub on Laravel, organized around the load.

Dispatchers group incoming sales orders geographically into loads, offer each to a haulier with driver, truck, and trailer assigned, then follow it from pick to weighbridge to delivery. Proof of delivery is captured on arrival, and invoicing comes from the loads actually run.

meridian · /loads-planning

Loads Planning screen: cards grouped under date headers, each with weight and volume fill bars, drop counts, and a truck suggestion.
[fig. 2] Loads Planning. The date-grouped card board: W | V capacity bars driving the rigid-vs-trailer-truck suggestion, drop counts, an off-sell badge, and the assign-or-edit action.

One core, four roles

Divisions, roles, and what happens when a driver has no signal.

One codebase serves three division portals, with APIs for four client roles (driver, haulier, picker, and merchant) consumed by native companion apps with real-time notifications and per-load chat.

Drivers out of signal record their deliveries offline and sync them on reconnecting.

A modular Laravel core rather than microservices: APIs scoped per role, capture that keeps working offline, and an ERP layer that is safe to retry.

meridian · driver-app

Two phone screens of the driver app: a drop list for the day’s load with an offline banner, and a proof-of-delivery screen with product lines, signature, and photo slots.
[fig. 3] Driver app. The day’s drop list with the offline queue banner, and per-company proof of delivery: product lines, signer, signature, POD photos, and pallets returned. Synced in batch once the driver is back in signal.

Migrating the ERP link

A mainframe swapping CSV files over FTP, replaced without a big-bang cutover.

I replaced the mainframe CSV-over-FTP exchange with a REST integration into Microsoft Dynamics 365 Business Central: safe to retry, and switched over in stages rather than in one jump.

It shipped with API documentation and a set of test cases, handed to the client’s ERP implementation partner. Engineers who would never open this codebase had to be able to read it and test against it.

Have an integration like this one to inherit? A fixed-price read of what you already have, written up in 1–3 days, before anyone commits to a migration.
Read About the Audits

meridian · /integrations

Integration monitor listing three batch imports with cadence and error counts, a retry backlog of unsent files with attempt counts, and an import-notification feed.
[fig. 4] Integration monitor. The file-batch reality: five-minute import cadence, errored files, the UNSENT retry backlog with attempt counts, and the scheduled tasks behind it.

What changed

  • One view of a delivery: planned, dispatched, weighed, proven, and invoiced in one system, across three division portals.
  • ERP link: from blind to observable: authenticated, safe to retry, and switched over in stages instead of in one jump.
  • Paper PODs stopped living in the glovebox, per company: signature, photo, and pallets returned, captured offline in the field and attached to the order the office sees.

Have a system like this to build, or inherit?

Tell me what you’re coordinating and where it stands: greenfield, mid-flight, or handed over from someone else.

Book a Free Call