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.
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
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
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
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.
meridian · /integrations
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.