Insights · 11 min read
A practical guide to building a last-mile delivery platform: dispatch, routing, the driver app, proof of delivery, and what a build actually costs.
By GGP Editorial
Most teams that say they want a last-mile delivery platform actually want a tracking page, or a driver app, or a route list that lives in a spreadsheet. A real last-mile delivery platform is the operations layer between an order and a completed drop-off: it takes in orders, decides which driver takes which stop, builds the route, tracks the van in real time, collects proof of delivery, and feeds the result back into billing and analytics. It is logistics infrastructure, not a feature.
I write this from the vendor side. GlobeSoft is a software company founded in 2018 with 40-plus engineers and more than 300 delivered projects for over 100 clients, and we build custom software, mobile apps, and IoT platforms for clients across the US, Brazil, South Africa, and Singapore. This guide covers what a last-mile delivery platform is, the modules that matter, the dispatch engine that does the heavy lifting, what a build costs, and the mistakes that sink these projects.
A last-mile delivery platform is the software that moves a package or order from a local depot or store to the customer's door. It takes orders in from an ERP, an e-commerce site, or a warehouse system, decides who delivers what and in what order, tells the driver where to go, shows the customer where the van is, records that the drop-off happened, and reports the result back to whoever pays the invoice.
Three products get confused with it, and the confusion produces the wrong scope.
A food delivery app is a marketplace. It connects restaurants, customers, and couriers and handles ordering, menus, and payments. Its hard part is the marketplace and the unit economics, not the routing. We wrote about that in how to build a food delivery app.
Fleet management software is about vehicles. It tracks location, fuel, maintenance, and driver behavior for a company running its own vehicles. It does not plan stops or collect delivery proof. See how to build fleet management software.
A warehouse management system or a TMS moves freight between facilities. A WMS handles inventory inside the building; a TMS handles line-haul trucking. The last-mile platform is the final leg, from a local hub to a door, and that leg has different math. We covered the broader picture in how to build supply chain management software.
If you run a courier operation, a retailer doing its own delivery, a grocery or pharmacy chain, or a 3PL that handles local drops, the last-mile platform is what you are building.
The happy path is simple. An order arrives from a web store, an ERP, a POS, or an API. The system assigns it to a driver, either automatically or through a dispatcher. The driver gets a stop list and a route, runs it, captures a photo or signature at the door, and marks the order delivered. The customer saw the van approaching and the order completed on time.
The system's real value shows up in the unhappy paths, which are most of the day.
A driver calls in sick at 6am and his stops need reassigning. A customer is not home, so the order goes to retry or return-to-origin. A van breaks down mid-route. A road closes and every ETA behind it shifts. An order needs a signature and a photo and the driver's battery dies. The platform absorbs all of this without the dispatcher re-planning by hand in a spreadsheet.
Here is the split between what you need at launch and what can wait.
| Must have in v1 | Can wait |
|---|---|
| Order intake (API, CSV, or manual entry) | Multi-depot planning |
| Dispatch console with a live map | Driver settlement and payouts |
| Route optimization | Customer-facing mobile app |
| Driver app (Android, likely iOS later) | Telematics and ELD integration |
| Real-time tracking and ETA | Returns and return-to-origin workflow |
| Proof of delivery (photo, signature, barcode) | Dynamic pricing and demand forecasting |
| Status updates (SMS or push) | Carrier and 3PL integrations |
| Delivery analytics and exception handling | Voice navigation inside the driver app |
Two of these are worth singling out.
The dispatch console is the product. It is the screen your operations team lives in: a map of every driver and every open order, with tools to assign, reassign, and re-sequence stops. If this screen is bad, the whole platform is bad, because everything else just feeds it data.
The driver app is where the delivery actually succeeds or fails. It has to be simple enough to use at the door in the rain, and it needs an offline mode. Drivers go into basements, parking garages, and rural dead zones. If the app needs a signal to show the next stop or capture a photo, deliveries fail. Store the stop list and pending photos locally and sync when the connection returns.
Route optimization sounds solved. It is not, and the gap between "sort the stops by distance" and "a route a driver can actually run" is where most delivery software fails.
A real routing problem has constraints. Drivers have shift windows. Some stops need a time window, like a pharmacy delivery that must arrive before noon. Vehicles have capacity, and vans come in different sizes. Some drivers know certain neighborhoods; some deliveries need two people or a refrigerated vehicle. Traffic is not static, so the same stop list routes differently at 9am than at 5pm.
Sorting stops by distance ignores all of that. A driver following a naive route hits locked doors, runs past his hours, and spends the afternoon backtracking.
You have two realistic paths. You can build the optimizer yourself on an open-source solver like Google OR-Tools, which is real engineering work and needs someone who understands the constraints, not just the library. Or you can integrate a routing service such as Mapbox or GraphHopper and pay per request or per vehicle. Most first-time builders should integrate first and build their own optimizer only when volume and specific constraints justify it. This is the same build-versus-buy logic we use for AI features, which we walked through in how to build a recommendation engine.
Customers forgive a late delivery. They do not forgive a wrong ETA that changes every five minutes, or a tracking page that says "out for delivery" from 8am until 9pm.
Tracking is the easy part: the driver app sends a GPS ping on an interval, and you plot it on a map. ETA is the hard part, because it combines the route the driver is actually following, live traffic, and the remaining stops, and it has to be honest about uncertainty. A good system shows a window that narrows as the driver gets closer, and it notifies the customer when the van is a few stops away, not when it is "on the way" in the morning.
This is also where the platform talks to your customer-facing channels. Push notifications and SMS are table stakes. The ETA and the "your driver is next" message are the two messages that actually reduce failed deliveries, because they get the customer to the door.
Delivery platform costs are driven by five things, in rough order of impact.
The dispatch and routing layer. Manual dispatch with a good map is cheap. Automatic assignment and constrained route optimization are a data product, and they are where the engineering budget goes.
The driver app. One platform (Android) keeps it simple. Two platforms (Android and iOS) roughly double the mobile cost. We break down the mobile numbers in mobile app development cost.
Integrations. Order sources (ERP, WMS, e-commerce), mapping and routing services, SMS and push providers, and payment for driver settlement all add up. Every integration is a small project of its own.
Real-time scale. Tracking thousands of drivers pinging every few seconds is a different infrastructure problem than tracking a hundred. The streaming layer has to be designed for it from the start.
Team and location. A delivery platform needs a product manager, a designer, two to four backend engineers, one or two mobile engineers, and a QA lead. Where that team sits changes the bill a lot. We compare the numbers in software development cost in China.
As a rough guide, an MVP with order intake, a dispatch console, route optimization through an integrated service, an Android driver app, tracking, proof of delivery, and basic analytics usually lands between $80,000 and $180,000. A full platform with automatic dispatch, a custom optimizer, iOS and Android, driver settlement, a returns workflow, and a customer app runs $250,000 to $600,000 or more. These are ranges, not quotes, and the only number that matters is the one from a scoped proposal. We wrote about getting that number in how to estimate a custom software project.
A focused MVP runs four to six months from kickoff to a pilot with a handful of drivers. A full platform runs nine to fifteen months. The mobile app and the dispatch console are usually the critical path, so start the driver app early and get real drivers using it on real routes as soon as it is barely usable. The feedback from a week of live runs is worth more than a month of internal testing.
Building the customer-facing stuff first. The tracking page and the branded app are the last thing that matters. The dispatch console and the driver app are what make the operation run.
Ignoring exceptions. Most delivery software demos show the happy path. The product lives or dies on retries, returns, reassignments, and failed drops. Design those flows before launch, not after the first support ticket.
Skipping offline mode. This one kills deployments in field trials. If the driver app cannot work without a connection, drivers abandon it and go back to phone calls and paper.
Underestimating ETA. Distance-based routing produces ETAs nobody trusts. If you cannot be honest about the window, do not show a precise time.
Treating dispatch as a feature. Dispatch is the core. A map with pins is not a dispatch system. The assign, reassign, and re-sequence actions are what you are paying for.
An MVP with order intake, a dispatch console, integrated routing, an Android driver app, tracking, proof of delivery, and analytics usually lands between $80,000 and $180,000. A full platform with automatic dispatch, both mobile platforms, driver settlement, and a customer app runs $250,000 to $600,000 or more. These are ranges; the real number comes from a scoped proposal.
A food delivery app is a consumer marketplace that connects restaurants, customers, and couriers and handles ordering and payments. A last-mile delivery platform runs the delivery operation itself: dispatch, routing, tracking, and proof of delivery, usually for a retailer, courier, or 3PL with existing orders.
Not at first. Integrating a routing service is the right start for most teams. Build your own optimizer only when volume and specific constraints, like time windows, capacity, and multi-depot planning, justify the engineering cost.
Order intake, a dispatch console with a live map, route optimization through a service, one driver app with offline mode, real-time tracking, proof of delivery, status notifications, and basic delivery analytics. Everything else can wait.
Four to six months for a focused MVP, nine to fifteen months for a full platform. Get the driver app in front of real drivers early; live feedback beats internal testing.
Android first, for a simple reason: most drivers use Android devices, and one platform keeps the mobile budget down. Add iOS when your own employees or a specific client base requires it.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa, and Singapore. We build custom software, mobile apps, SaaS platforms, IoT systems, and FinTech and ERP products on a stack that includes Java, Spring Boot, Go, Python, React, Vue, and Node. We run overlapping working hours with clients and communicate in English and Portuguese, which matters when you are coordinating a live delivery operation across time zones.
If you are planning a last-mile delivery platform, a courier dispatch system, or a delivery app, talk to us about your project. Tell us your fleet size, your order volume, and where the pain is today, and we will help you work through the build-versus-buy calls, the routing layer, and what to ship first.
Tell us what you are building and where you are today. We typically reply within 24 hours.
