Why we built multi-stop route optimisation into DropPilot

The moment we realised routing wasn't a nice-to-have

Before DropPilot existed, we spent months talking to drivers, dispatchers, and logistics managers. What struck us wasn't the complexity of their language. It was the exhaustion in their stories.

Most delivery software at the time offered one of two things. Either you got a mapping app that showed you point A to point B, and you spent your day manually dragging waypoints around on your phone screen. Or you got a fleet management system built for corporations, costing hundreds a month, buried in complexity, and making drivers feel like they were being watched rather than helped.

What nobody was solving for the solo courier or the small team was simple: how do you take a list of addresses and quickly figure out the sensible order to visit them?

James wasn't unusual. He was the norm. And that Tuesday message made it clear we couldn't ship DropPilot without getting route optimisation right.

Building something that actually runs in the real world

We could have licensed a heavyweight routing engine. But those carry baggage: complexity, cost, and they often assume you're running a delivery company at scale. We needed something that would work for a single driver with five stops, and equally well for a fleet manager juggling fifty vehicles.

So we built our own. Nearest-neighbour for the first pass (it's fast), then 2-opt optimisation to smooth out the rough edges and catch better sequences you'd miss manually. Nothing fancy in name, but it runs quietly and does the work.

The real move was coupling that with Google Directions API. A route that looks logical on a map isn't much use if it ignores actual traffic, roadworks, and the fact that it's rush hour. We pull live traffic data, refresh your ETA every few minutes, and if you deviate from the planned route, we detect it and recalculate.

That last bit matters more than it sounds. A driver isn't a robot. If a stop gets delayed, if weather forces a detour, if a customer calls and reschedules, the app adapts instead of sulking.

What happened when we put it in drivers' hands

Our first beta week was humbling. A food delivery driver in Liverpool told us the app had cut her round time by forty minutes. A field service technician in Leeds said he could finally finish early without feeling like he was missing something. A small courier outfit running three vehicles reported they'd stopped arguing about who got stuck with the awkward route.

But the feature that surprised us came from dispatchers. They asked whether they could upload a whole day's worth of addresses at once instead of tapping them in one by one. So we built CSV bulk import. A dispatcher can now upload a spreadsheet of fifty stops, and DropPilot sequences them instantly.

The proof of delivery side emerged from the same place. A driver said: "I have to phone the office to confirm I've been somewhere, then email a photo, then it gets lost. Why can't the app just handle it?" Now they capture signature or photo or typed notes right there at the stop, and it's timestamped and archived.

Why we kept it focused instead of feature-bloated

We could have added more. Barcode scanning, customer messaging, dynamic job allocation, integration with every logistics platform under the sun. And maybe someday we will.

But we started with a principle: don't build for an imaginary user. Build for the courier, the driver, the field engineer, the dispatcher doing the work right now.

Multi-stop routing had to be accurate and fast. Proof of delivery had to work on a dodgy 3G signal. Fleet dispatch had to let a manager see their team without needing an MBA in software. The free tier had to be genuinely useful so someone could try it without risk.

That constraint shaped everything. We didn't pad the roadmap with things that sound impressive in a sales pitch. We built what people actually asked for, tested it obsessively, and made sure it worked offline just in case the network dropped.

A tool that scales with you

This is the part that matters for the long game. A solo courier can use DropPilot for free, five rounds a month with five stops each. That's real work. When they grow to ten rounds a week, the Plus tier makes sense. When they're managing a team, Team tier gives them dispatch tools and shared access.

But the core engine doesn't change. Whether you're one person or twenty, the route optimisation works the same way because we built it to be honest about what it does, not oversold.

We've watched users stick with DropPilot because it solved a specific problem without trying to solve everything. A dispatcher in Glasgow told me recently: "It's not flashy. It just works, and I trust it." That sentence is worth more than any feature list.

The question that still matters

Every quarter, we get enquiries from people wanting to turn DropPilot into a delivery marketplace, or a customer-facing tracking app, or a hundred other directions. We say no to most of it because it would blur what we built it for.

DropPilot exists because drivers and dispatchers kept asking for one thing: a tool that lets them think about what matters instead of spending their day doing logistics admin. Multi-stop route optimisation was never the flashy headline feature. It was the answer to a real problem.