How to Build Courier and Last-Mile Delivery Management Software

A same-day courier operation handling 200 deliveries before noon can't manually assign stops to 12 drivers and still make 10am delivery windows. The dispatcher who builds routes in their head at 7am is the single point of failure. When they call in sick, everything stalls. Recipients get no warning. Drivers waste 40 minutes of drive time per route because the stop sequence isn't optimized. And when a delivery fails, nobody knows until the customer calls.

McKinsey's Future of Last-Mile Delivery report found that last-mile costs account for 41% of total supply chain cost. Route optimization alone can reduce that by 15-20% for dense urban operations.

Courier and last-mile delivery software solves this by automating route assignment, giving drivers a mobile job list, and keeping recipients informed without any dispatcher involvement.

What courier delivery management software does

"The biggest operational lever for any courier business isn't hiring more drivers -- it's reducing dead miles. A 10% improvement in route efficiency for a 20-driver fleet is the equivalent of two extra drivers for free." -- Marc Gorlin, founder of Roadie (acquired by UPS), in a 2022 logistics technology interview.

Order intake from multiple channels. Orders arrive via API from e-commerce platforms, through a web portal for manual entry, and by phone (staff-entered). Each order captures sender, recipient address, delivery window (start and end time), package description, weight, and special instructions.

Route optimization with multi-stop sequencing. The dispatcher triggers route generation each morning. The optimizer assigns orders to available drivers and sequences stops to minimize total drive time while respecting delivery windows.

Driver dispatch with mobile app. Each driver sees their assigned stop list on their phone. The app links directly to the navigation app for each stop. Drivers confirm arrival, capture proof of delivery, and mark stops complete.

Proof of delivery. At each stop, the driver captures a photo of the delivered package and collects a digital signature. Both are stored and attached to the order record.

Real-time recipient tracking link. When a driver is dispatched, the recipient gets an SMS with a tracking link showing the driver's current GPS position and estimated arrival time. The link expires after 48 hours.

Customer notifications. Automated SMS and email at three points: when the order is dispatched, when the driver is approaching (within 2 stops), and on delivery with the proof-of-delivery photo.

Billing by zone, weight, or route. Invoices generate per delivery run or per client account based on your pricing model. Weight-based and zone-based billing are both supported.

Failed delivery workflow. When a driver can't complete a delivery, they mark it failed with a reason code. The order re-enters the dispatcher queue for redelivery scheduling and the recipient gets an automated notification.

MVP vs. full platform

MVP includes:

• Order intake via web portal and manual entry

• Delivery time window capture per order

• Route optimization with multi-stop sequencing

• Driver mobile app with stop list, navigation link, and arrival confirmation

• Photo and digital signature proof of delivery

• Recipient tracking link via SMS

• Basic invoicing per delivery run

Full platform adds:

• API webhooks for e-commerce order sync (Shopify, WooCommerce)

• Route analytics and driver performance reporting

• Multi-depot management

• Return pickup scheduling

• Weight-based and zone-based billing automation

• Recipient rating and feedback collection

• Driver payroll reporting

Core architecture

Two core records carry the system.

The order record holds: sender, recipient address, delivery window (start_time, end_time), package description, weight, and a status state machine with states: pending, assigned, in_transit, delivered, failed. Proof of delivery is stored as S3 URLs (photo_url, signature_url) on the order record. The recipient tracking link is a public URL containing a signed token valid for 48 hours. It resolves to a page showing the driver's live GPS position and estimated arrival.

The route record holds: driver ID, date, ordered list of order IDs, total distance, and estimated completion time. The route is stored as a JSON document on the route record. When orders are added or cancelled mid-day, the dispatcher can trigger a re-optimization. Completed stops are anchored as fixed inputs to the solver so their sequence doesn't change.

The driver mobile app communicates via REST API: fetch assigned route, mark stop complete, upload proof-of-delivery images. Offline access to the stop list is critical. The app syncs the full route to local storage on login so drivers can view stops and capture proof of delivery in areas with no cell signal. Uploads queue locally and sync when connectivity returns.

The hardest technical challenge

Route optimization with delivery time windows is the hardest problem in this system. Google OR-Tools documentation describes VRPTW as NP-hard, meaning there is no algorithm that finds the provably optimal solution in polynomial time for large inputs. The practical answer is to use a good heuristic solver, not to try to build a perfect one.

Recipients specify windows: 9am-12pm, 2pm-5pm, or all-day. The optimizer must assign all orders to drivers and sequence stops such that each stop is reached within its window and total drive time is minimized. This is the Vehicle Routing Problem with Time Windows (VRPTW). It is NP-hard to solve optimally.

Do not build a custom routing algorithm. Use Google OR-Tools (open source, Python or C++, with a working Node.js wrapper) or a routing API such as Google Routes Optimization or OptimoRoute. For a fleet under 20 vehicles with 200 stops, OR-Tools solves in under 5 seconds.

Feed the solver four inputs:

1. A distance matrix computed via the Google Distance Matrix API using real road distances, not straight-line calculations. Straight-line calculations cause 15 to 25% route inefficiency in dense urban areas.
2. Time window constraints per order: earliest arrival time and latest arrival time at each stop.
3. Vehicle capacity constraints: maximum stops or total weight per driver.
4. Driver start and end depot locations: each driver begins and ends at the warehouse or their assigned depot.

The solver returns optimized routes. Store the route output as a JSON document on the route record.

The tricky part is re-optimization during the day. When a new order is added at 10am, or a driver calls in sick and their stops need redistribution, you need to re-solve without disturbing already-completed stops. Pass completed stops to the solver as fixed waypoints with zero time flexibility. Add a re-optimize button in the dispatcher UI that triggers a fresh solve respecting this constraint.

One more edge case: time windows that are impossible to satisfy. Before sending routes to drivers, validate that every order has a feasible time window given current fleet size and depot location. Surface infeasible orders to the dispatcher before dispatch, not after drivers are already on the road.

Build costs and timeline

RaftLabs has scoped and built dispatch platforms with route optimization for logistics operators across the UK and Australia. The numbers below reflect real build experience, not estimates from a pricing calculator.

MVP (order intake, route optimization, driver mobile app, proof of delivery, recipient tracking links, basic invoicing): $120K to $200K over 12 to 16 weeks.

Team: 1 backend engineer, 1 mobile developer (React Native), 1 frontend engineer for the dispatcher web app, 1 QA engineer. The route optimization module, including the solver integration and distance matrix caching layer, accounts for roughly 20% of the backend development time.

Full platform (adds e-commerce API sync, multi-depot, route analytics, weight-based billing automation, recipient ratings): $240K to $390K over 20 to 28 weeks.

Ongoing infrastructure runs $1K to $4K per month. Google Maps API fees scale with delivery volume. At 500 deliveries per day, expect $300 to $600/month in Maps API costs alone. Cache distance matrices aggressively to keep this in check.

Build vs. buy

Onfleet starts at $500/month for up to 2,000 tasks/month. Strong driver app and tracking. Limited API flexibility and billing customization.

OptimoRoute is $35 per driver per month. Good route optimization. No white-label option. API is read-only on lower plans.

Route4Me starts at $200/month for basic routing. Add-ons for time windows and API access push the real cost to $400 to $800/month.

Circuit starts at $100/month for small teams. Focused on simplicity. No multi-depot or custom billing.

Build when you have 15 or more drivers, need API integration with shipper systems, or need zone-based billing that generic routing apps don't support. Also build when you're a logistics tech startup creating a branded delivery platform for clients who expect your app on their drivers' phones, not a third-party tool.

Tech stack

Backend: Node.js with PostgreSQL. PostgreSQL handles the order and route records cleanly. The route JSON document stores the optimizer output on the route record.

Route optimization: Google OR-Tools via a Python microservice called from Node.js. The Python service receives solver inputs (distance matrix, time windows, capacity constraints) and returns the optimized route assignments. Alternatively, use the Google Routes Optimization API if you want a managed service.

Distance matrix: Google Distance Matrix API. Cache results in PostgreSQL with a 24-hour TTL. Distance between two addresses rarely changes, so caching cuts API costs by 60 to 80% for repeat address combinations.

Driver mobile app: React Native. Offline-first architecture with local SQLite for stop list storage. Background location tracking sends GPS coordinates to the API every 30 seconds while a route is active.

Proof of delivery storage: AWS S3 with folder structure by date and driver ID. Store S3 URLs on the order record.

Recipient notifications: Twilio for SMS. Estimated arrival calculations trigger 30-minute advance notifications using the driver's current GPS position and remaining route distance.

Dispatcher web app: React. Real-time driver location updates via WebSocket or server-sent events. Map view with Mapbox or Google Maps JavaScript API.

Tracking page: Public Next.js page with a signed JWT in the URL parameter. The token encodes the order ID with a 48-hour expiry. The page polls the driver location API every 60 seconds.