Logistics software is a real time systems problem disguised as a CRUD app. On the surface, you have orders, drivers, routes, and deliveries. Underneath, you have GPS streams updating every 5 seconds, ETAs recalculating on the fly, proof of delivery workflows that need to work offline, and dispatch logic that has to account for vehicle capacity, driver hours, traffic, and customer time windows. We have built tracking platforms that process thousands of location updates per minute, and the architecture decisions you make in week one determine whether the system scales or collapses under load.
When Custom Logistics Software Makes Sense
The logistics SaaS market is crowded. Onfleet, Route4Me, and Track POD cover basic last mile delivery. But the moment your operations deviate from standard, such as multi stop routes with mixed cargo types, temperature sensitive deliveries, chain of custody requirements, or integration with warehouse management systems, you hit the walls of these platforms fast.
Custom makes sense when you have proprietary routing logic, regulatory compliance requirements, integration needs with existing ERP or WMS systems, or when your delivery volume makes per delivery SaaS pricing economically painful. A company doing 1,000 deliveries per day at $0.10 per delivery is paying $36,500 per year for basic tracking. A custom built platform costs more upfront but eliminates that recurring cost and gives you exactly the features you need.
Core Architecture
The platform breaks into four major subsystems:
1. Order Management. Orders come in from multiple channels, including APIs from e commerce platforms, EDI from enterprise customers, manual entry from dispatch, and scheduled recurring deliveries. Each order has pickup and delivery addresses, time windows, cargo specifications, and priority levels. The API layer needs to handle high throughput during peak ordering periods and validate addresses against a geocoding service before they enter the system.
2. Dispatch and Route Optimization. This is where the intelligence lives. A basic implementation assigns orders to drivers manually. A good implementation groups orders by geography, calculates optimal routes considering time windows and vehicle capacity, and presents dispatch recommendations that a human can approve or modify. For route optimization, we integrate with the Google Routes API or OSRM (Open Source Routing Machine) depending on volume and budget. Google charges per route calculation, so high volume operations should self host OSRM.
3. Real Time Tracking. Drivers broadcast their GPS position from a mobile app. The server ingests these updates, associates them with active deliveries, recalculates ETAs, and pushes updates to customers and dispatchers. This is a real time architecture problem that requires WebSocket connections for the dashboard and push notifications for customers.
4. Proof of Delivery. When a driver completes a delivery, they capture a photo, collect a signature, scan a barcode, or record a PIN confirmation. This proof needs to work offline because drivers are frequently in areas with poor connectivity, such as parking garages, rural areas, and building interiors. The mobile app queues proof data locally and syncs when connectivity returns.
Data Model Design
The core entities and their relationships:
Order contains origin address, destination address, customer reference, time window, cargo details (weight, dimensions, temperature requirements), priority, and status.
Route groups multiple orders into a sequence with a driver assignment, vehicle assignment, estimated start time, and estimated completion time.
Driver has availability schedules, vehicle assignment, current location, active route reference, hours logged today, and certification flags (hazmat, refrigerated, oversized).
Delivery Event is an append only log that records every state change: assigned, en route to pickup, arrived at pickup, picked up, en route to delivery, arrived, delivered, failed. Each event carries a timestamp, GPS coordinates, and optional attachments.
This event sourced approach to delivery state is critical. You never update a delivery status in place. You append events. The current status is derived from the latest event. This gives you a complete audit trail, makes disputes trivial to resolve, and enables powerful analytics.
The GPS Ingestion Pipeline
This is the most technically demanding component. A fleet of 200 drivers sending GPS updates every 5 seconds generates 2,400 updates per minute. At 1,000 drivers, that is 12,000 per minute.
We recommend a pipeline architecture:
1. Mobile app sends batched GPS updates every 10 to 15 seconds via HTTPS
2. Ingestion API validates and writes to a message queue (Redis Streams or AWS SQS)
3. Processing workers consume the queue, update driver positions, recalculate ETAs, and trigger geofence events
4. Real time broadcast pushes position updates to connected dashboard clients via WebSockets
5. Cold storage writes historical positions to a time series table for analytics and playback
Geofencing is how the system automatically detects arrivals and departures. You define a radius around each pickup and delivery address. When a driver enters that radius, the system triggers an "arrived" event. When they leave after a delivery, it triggers "departed" and starts navigation to the next stop.
Driver Mobile App
The driver app is the field interface and arguably the most important piece of the system. It needs to:
- Display the active route with turn by turn navigation integration (deep linking to Google Maps or Waze)
- Show stop details including customer name, address, special instructions, and time window
- Capture proof of delivery with camera, signature pad, barcode scanner, and notes
- Work offline for all critical functions, syncing when connectivity returns
- Report position in the background even when the app is not in the foreground
For mobile development, we build driver apps with React Native. It provides native performance for background location tracking while sharing business logic with the web dashboard. The offline sync layer uses a local SQLite database that queues operations and resolves conflicts when back online.
Customer Facing Tracking
Customers expect Amazon level tracking visibility. At minimum, provide:
- Tracking page accessible via a unique link sent by SMS or email, no login required
- Real time driver position on a map with ETA
- Status timeline showing each milestone (order confirmed, driver assigned, picked up, en route, delivered)
- Delivery confirmation with photo and signature displayed after completion
The tracking page should be a lightweight, fast loading web page, not a full app download. We build these as static pages that connect to a real time data stream for live updates. Sending the tracking link is typically automated through the notification system when a driver starts a route.
Dispatch Dashboard
The dispatch dashboard is a command center that shows:
- Map view with all active drivers, their routes, and delivery statuses color coded
- Route board showing each driver's assigned stops, completion percentage, and time performance
- Exception alerts for late deliveries, failed attempts, driver inactivity, and SLA breaches
- Order queue for unassigned orders that need to be dispatched
Real time is non negotiable here. Dispatchers need to see position updates within 2 to 3 seconds of the driver's actual movement. We use WebSocket connections with reconnection logic and optimistic UI updates to maintain responsiveness.
Analytics and Reporting
Logistics operations live and die by metrics:
- On time delivery rate broken down by driver, route, time of day, and day of week
- Average deliveries per hour measuring driver productivity
- Cost per delivery including fuel, labor, and vehicle depreciation
- Failed delivery rate with reason codes (customer not available, wrong address, access issue)
- Route efficiency comparing planned vs actual route time and distance
These reports inform operational decisions. If on time rates drop on Fridays, you know you need more drivers. If a specific zone consistently has failed deliveries, you adjust time windows or customer communication.
What It Costs to Build
A production ready logistics platform with order management, dispatch, driver app, customer tracking, and basic analytics takes 4 to 6 months with a team of 3 to 5 engineers. The driver mobile app alone accounts for 30 to 40 percent of the effort due to offline support, background location tracking, and proof of delivery workflows. If you want to understand the broader cost of custom software, we have a detailed breakdown.
We recommend launching with core tracking and dispatch as a minimum viable product, then layering on route optimization, analytics, and integrations in subsequent releases. This gets the system into drivers' hands faster and lets real usage data inform feature priorities.
If you are running a delivery operation and your current tools are creating bottlenecks, reach out to talk about what a custom platform would look like for your business.