RouteFlow — Logistics case study

Manual route planning doesn't scale

Each morning a single dispatcher opened a spreadsheet, cross-referenced driver locations, delivery windows and vehicle capacity by eye, and built that day's routes from scratch — a process that took close to three hours before the first van could leave. That's workable for a ten-stop day. It breaks down the moment order volume passes what one person can hold in their head, or a driver calls in sick and the whole plan needs redoing mid-morning.

What we built

We replaced the spreadsheet with a live planning engine end to end:

• Webhook-based ingestion from the existing order system — no manual export step
• A constraint solver that builds routes against driver shifts and vehicle capacity automatically
• Automatic re-planning when an order or driver status changes mid-morning
• Route output pushed directly to drivers' existing handheld scanners

Why we didn't just add a "smart" route sort

The easy version of this project sorts existing stops by distance and calls it optimisation — it's a half-day build, and it's what most off-the-shelf tools default to. It falls apart the moment two drivers have different shift end times or a van can't fit what's assigned to it, because a distance sort has no concept of those constraints and will happily build a route no driver can actually complete. We built a proper constraint solver instead — slower to ship, but it treats shift windows and vehicle capacity as hard limits rather than an afterthought, which is the difference between a route that looks efficient on paper and one a driver can actually run.

The stack

Workflow orchestration handles the ingestion and re-planning triggers, a constraint-solving service builds the routes, and the courier's existing order system and handheld scanners stay as the source and endpoint — nothing for the driver-facing team to relearn.