Case Study · Optiway
A dispatch platform that turns a list of stops into sequenced, balanced routes, and a driver app that carries them to the door, built as one product rather than two. We worked on Optiway as an embedded engineer inside the client's own team, on the live route predictability algorithm behind its sequencing and its arrival times.
Optiway is route optimization software for last mile delivery. A dispatcher drops a day’s stops into it, presses one button, and gets routes sequenced for the shortest realistic drive, balanced across the drivers available and dispatched straight to the phones in their pockets. The platform is two halves of one product: a dispatch application for the office and a driver app for the road, with the routing engine between them. It runs for couriers and parcel fleets, grocery and food delivery, furniture and appliance installers, pharmacies, 3PL operators, field service technicians and solo drivers, and its own published figures put it at over 100,000 customers, more than five million deliveries optimized, and delivery costs down by a quarter for the teams running it.
Our part in it was narrow and worth stating plainly. Optiway is the client’s platform, built by the client’s team. We joined that team on a staff augmentation basis with one engineer, embedded in their process rather than running a workstream of our own, and the work was the live route predictability algorithm: the k nearest neighbours approach that decides which stop follows which and keeps the arrival times the platform quotes standing up as the day moves. Nothing else on this page is a claim about what we built.
One structural fact shapes the rest of the study. A route plan is a promise made at eight in the morning to a customer who will be waiting at four in the afternoon, and between those two moments a stop gets added, a driver drops off, a street closes and traffic does what traffic does. Optimizing once is a spreadsheet problem. Staying optimized is the product, and it is the half the routing algorithm lives in.
The last mile is the expensive one. Everything before it moves in pallets down motorways; the last leg moves in ones and twos through residential streets, and it is where the fuel, the overtime and the failed deliveries land. Most of the teams driving it plan by hand: a spreadsheet of addresses, a maps app with the stops typed in, and a dispatcher who knows the area well enough to guess at a running order.
That guess is the problem. A general navigation app drives the stops in the order they were entered, which is the order they came off the order system, which is no order at all. Deliveries that should be consecutive end up an hour apart, the same street gets driven three times, and the planning itself eats the start of every morning. Optiway’s own comparison puts the same list at two hours fourteen driven as entered against one hour twenty two sequenced, and the planning overhead at forty five minutes against under three.
And the plan is not the day. A route leaves the depot and then a stop is added, a driver calls in sick, a delivery window turns out to be tighter than anybody read it, and traffic rearranges the middle of the afternoon. Every arrival time quoted to a customer that morning depends on a sequence that stopped being true by ten. Getting the first order right is arithmetic. Keeping it right, and keeping the estimated arrival times honest while it changes, is the harder half.
What follows is Optiway, end to end: how a day’s stops get in, how they are sequenced, how they reach a driver, how the sequence holds up once the vans are moving, and what the week looks like afterwards. It is the client’s platform and their team’s work. One of these six is the piece our engineer worked on, and it is marked.
A delivery day starts as a mess of addresses in whatever the order system exports. Optiway takes it as it comes: upload a CSV or a spreadsheet, paste a list, type a stop in by hand, dictate it, or push orders in over the API. Each address is validated against Google Maps on the way in and checked against the stops already in the day, so the plan is built on addresses that exist and none of them twice.
Optimize route is the whole planning step. Optiway sequences every stop into the fastest realistic order, splits the load across the drivers on shift and respects the delivery windows attached to each one, with live traffic in the arithmetic rather than added to it afterwards. Their own before and after puts the same run at 18.5 km driven as entered against 12.6 km sequenced.
A sequenced route is still a plan until somebody has it. Drivers are picked from the account, the day is split between them, and one action pushes every route to the phone that will run it, colour coded on the board so a dispatcher can see the whole depot at a glance. Nothing is printed, nothing is read out over the phone, and the driver opens the morning already knowing the plan.
This is the part we worked on. Optiway does not sequence a route once and hope; it watches where each driver actually is, which stops are done and what the road is doing, and keeps the remaining order and the arrival times it has quoted in step with all three. Our engineer worked inside the client's team on that live route predictability algorithm, a k nearest neighbours approach to deciding which stop should follow the one a driver has just finished. It is one engineer's contribution to somebody else's platform, and it sits in the half of the product that has to be right after the plan has stopped being true.
The driver app is the other half of the product and it is deliberately small. The route, the next stop, the time saved against driving it as listed, and three buttons: navigate, done, failed. Navigation hands off to whichever map app the driver already trusts rather than asking them to learn a new one, proof of delivery is captured at the door, and the app keeps working through dead zones and syncs when the signal comes back.
Every route leaves a record behind it, and the analytics screen is where a fleet stops arguing from memory. Completed stops, failed deliveries, distance driven, average time per stop and a completion rate per driver, over whatever window matters, exportable in one click. It is the difference between believing the routing is working and being able to show it.
A photo, a signature and a note captured the moment a stop is delivered, so every order is verifiable end to end and the where is my parcel call has an answer before it is made.
A delivery window is a hard constraint in the optimization rather than a note on the stop, and an urgent order marked high priority is routed first. The sequence has to satisfy both before it is offered.
Turn-by-turn navigation opens in Apple Maps, Google Maps, Waze or Here WeGo. A driver who has spent five years in one of them does not have to give it up to use the route.
The app keeps delivering through dead zones and syncs everything the moment the connection is back, which matters because the places a route goes wrong are rarely the places with four bars.
Only dispatcher seats are billed, so adding a driver never costs anything. A fleet that grows in the summer is not choosing between coverage and licence count.
Route reports in PDF or Excel and stop data in CSV, with details, arrival times and activity logs, so completed deliveries can be documented in whatever system the business already runs its accounting in.
Optiway sells the routing on what it saves, and the numbers it publishes are its own: delivery costs down by 25% or more, two hours a day off route planning, and drivers finishing up to two hours earlier. More than five million deliveries have been optimized through it and its driver app carries a 4.8 rating across a thousand ratings on the App Store, which for a tool somebody uses forty times a day is the harder of those two figures to earn. The teams running it are couriers, pharmacies, grocers, furniture fitters and 3PL operators, and the thing they have in common is that the route was previously a guess.
Our part in that was one engineer, embedded in the client’s team on a staff augmentation basis, working on the live route predictability algorithm underneath it. That is the engagement Nortik is built to run: a senior engineer inside somebody else’s team, on the part of their product that needed a specialist rather than another pair of hands, accountable to their roadmap and their standards rather than to a statement of work of our own. The platform is theirs. The sequencing problem is the kind of thing we get sent.
