This case study documents how Lycore built a custom logistics platform development project for a UK-based distribution company that reduced operational costs by 30% within twelve months of deployment. The platform replaced a combination of manual spreadsheet processes, a legacy TMS that had not been updated since 2016, and a third-party route planning tool that did not integrate with the company’s warehouse management system. The result was a unified logistics platform covering order ingestion, intelligent route optimisation, real-time driver tracking, automated dispatch, and customer delivery notifications – built on Django and React with a PostgreSQL backend and deployed on AWS.
The Problem: Fragmented Logistics Operations Driving Unnecessary Cost
Before the custom platform, the distribution company’s logistics operation ran across four disconnected systems. Orders arrived via email and phone and were manually entered into the legacy TMS. A separate route planning tool generated daily routes that had to be manually transferred to driver manifests. Drivers communicated status updates by phone, with a dispatcher manually updating delivery records throughout the day. Customers received no proactive delivery updates, generating high inbound call volume to the customer service team.
The cost implications were direct and measurable. Manual data entry between systems created errors that required correction, adding administrative overhead estimated at 12 hours per day across the dispatch team. Route planning was done once each morning and could not adapt to delays, traffic, or late order additions without a full manual replanning cycle. Fuel costs were higher than necessary because routes were not optimised for vehicle capacity utilisation – vehicles were frequently dispatched at 60-70% capacity when consolidation would have allowed the same deliveries with fewer vehicles. Customer service handled 150-200 inbound calls per day about delivery status, representing approximately 2.5 full-time equivalent staff time.
Why a Custom Logistics Platform Development Approach Was Chosen
The company evaluated three commercial TMS platforms before engaging Lycore. Each addressed some of the problems but not all. The core issue was integration: the company’s warehouse management system (a bespoke system built in 2011) had no standard API, and all three commercial platforms required a manual export/import process to receive order data from it – recreating the same integration gap that was driving the manual data entry overhead. A custom logistics platform development project allowed the warehouse system integration to be built directly, alongside the route optimisation, tracking, and dispatch features, in a unified data model without the seams that commercial platforms would have required.
Technical Scope and Constraints
The platform needed to: ingest orders in real time from the legacy warehouse system via a custom integration layer; build daily route plans optimised for vehicle capacity, time windows, and driver working hour limits; dispatch routes to drivers via a mobile app with turn-by-turn navigation; track vehicle positions in real time; trigger automated customer notifications at key delivery milestones; and provide a management dashboard with operational KPIs. The constraint was a twelve-week timeline to the first production deployment and a budget of GBP 95,000 for the initial platform. This required a pragmatic architecture decision: use proven open-source route optimisation rather than building a proprietary solver, and build the mobile driver app as a progressive web app rather than a native iOS and Android application to avoid platform-specific development overhead.
Logistics Platform Development: Technical Architecture
The platform architecture was designed around three core bounded contexts: order management, route planning, and execution and tracking. Each maps to a Django application with its own data models and business logic, connected via internal Python service interfaces rather than microservice APIs – the scale and team size did not justify the operational overhead of a distributed architecture.
Route Optimisation Engine
The route optimisation engine is the technical heart of the platform. We used OR-Tools (Google’s open-source combinatorial optimisation library) to solve the vehicle routing problem with time windows (VRPTW) – the variant that accounts for delivery time window constraints as well as vehicle capacity and driver working hours. OR-Tools’ constraint programming solver handles fleets of up to 30 vehicles and 500 daily delivery stops within the 30-second planning time budget required for interactive replanning. The optimisation objective minimises total route distance weighted against vehicle utilisation – a pure distance minimisation approach was rejected because it produced routes with low vehicle fill, which was the primary cost driver the client wanted to address. Route planning runs as a Celery task triggered at 05:30 each morning for same-day routes and on-demand for emergency replanning. A React-based planning dashboard lets the dispatch team review proposed routes, make manual adjustments, and approve dispatch – human oversight before automated dispatch was a non-negotiable operational requirement from the client.
Real-Time Tracking and Driver Mobile App
Driver location is captured via a Progressive Web App running on company-issued Android phones. The PWA posts GPS coordinates to a Django WebSocket endpoint every 30 seconds when a route is active, and on each delivery event (arrived, delivered, attempted). Django Channels handles the WebSocket connections, with Redis as the channel layer. The dispatch dashboard subscribes to vehicle position updates via WebSocket and renders live vehicle positions on a Leaflet.js map with route overlays. Driver updates – delivery confirmations with optional photo capture, exception reporting, and electronic proof of delivery – are submitted through the PWA and stored against the delivery record in real time. The decision to use a PWA rather than a native app saved approximately four weeks of development time and eliminated the need for separate iOS and Android development tracks. The trade-off was slightly reduced access to device hardware features, which was acceptable for this use case where GPS, camera, and notifications were the only native capabilities required.
Warehouse System Integration: The Hardest Part
Integrating with the legacy warehouse system was the highest-risk component of the project and the primary reason a commercial TMS had not solved the problem. The warehouse system had no REST API. It exposed a SQL Server database that the warehouse system vendor did not support direct external access to, and a file export function that produced fixed-width text files in a proprietary format on a scheduled basis.
Building a Custom Integration Layer
The integration approach used the file export as the primary data feed, enhanced with a change-data-capture mechanism. A lightweight Windows service (written in Python, packaged with PyInstaller) ran on the warehouse system’s application server, monitoring the export directory for new files, parsing the fixed-width format, normalising the data into a clean JSON structure, and POSTing it to the logistics platform’s inbound API over HTTPS. New orders were delivered to the logistics platform within 90 seconds of being confirmed in the warehouse system – not real-time, but fast enough for same-day route planning. Outbound status updates (delivery confirmations, exceptions) were written back to the warehouse system via a separate file import mechanism that the warehouse system vendor supported. This bidirectional integration required significant reverse engineering of the file format and extensive testing with the warehouse team, but it was the only viable approach given the constraints.
Data Quality and Reconciliation
File-based integration between systems is inherently fragile compared to API integration. The integration layer included error detection for malformed records, a dead-letter queue for records that failed validation, a daily reconciliation job that compared order counts and status between the warehouse system export and the logistics platform database, and alerting for discrepancies above a threshold. In the first month of production operation, the reconciliation job identified three categories of data quality issues in the warehouse system exports that had previously gone undetected because there was no automated comparison. Fixing those upstream data quality issues reduced manual dispatch corrections by approximately 40%.
The 30% Cost Reduction: How It Was Achieved
The 30% operational cost reduction was measured over the twelve months following go-live, compared to the equivalent period in the prior year adjusted for volume changes. It came from four distinct sources, each quantified separately.
Vehicle Utilisation and Fuel Savings
Average vehicle utilisation improved from 68% to 89% of capacity through OR-Tools route consolidation. This reduced the daily vehicle count required to service the same delivery volume from an average of 22 vehicles to 17, a saving of approximately 5 vehicles per day. Combined with route distance reduction from optimised sequencing, total fuel expenditure fell by 23% year on year. This was the single largest cost reduction component, accounting for approximately 14 percentage points of the 30% total reduction.
Administrative and Dispatch Labour Savings
The elimination of manual data re-entry between systems, automated route generation replacing manual planning, and automated customer notifications replacing manual status call handling reduced the dispatch and customer service team workload sufficiently to redeploy two full-time staff to other operational roles without increasing headcount. The administrative overhead reduction accounted for approximately 9 percentage points of the total cost reduction.
Failed Delivery Reduction
Proactive customer delivery notifications (SMS and email triggered at route start and one hour before estimated arrival) reduced failed delivery attempts from 8.2% to 3.1% of deliveries. Failed deliveries are one of the most expensive events in last-mile logistics – redelivery costs roughly the same as the original delivery but generates no additional revenue. Reducing failed deliveries from 8% to 3% on a volume of 1,200 daily deliveries saved approximately 60 redeliveries per day. This accounted for approximately 7 percentage points of the total cost reduction.
Lessons from the Logistics Platform Development Project
Several decisions made during the project had outsized impact on its success. These are worth documenting for teams planning similar logistics platform development projects.
Use Open-Source Optimisation Rather Than Building a Solver
OR-Tools is mature, well-documented, and capable of solving real-world VRPTW problems at the scale most distribution companies operate at. Building a custom route optimisation solver from scratch would have consumed the entire project budget and timeline without producing meaningfully better results. The pragmatic choice to use OR-Tools and spend the engineering effort on integration quality, UX, and operational tooling was one of the most important decisions of the project.
Invest in the Integration Layer
The warehouse system integration was scoped at 15% of the project budget. In practice, it consumed 25%. Legacy system integration is consistently the most unpredictable and most time-consuming component of logistics platform development projects. Budgeting generously for it – and building the reconciliation and error-handling infrastructure around it – pays dividends throughout the system’s operational lifetime. Integration problems discovered in production are far more expensive to fix than those caught by comprehensive integration testing.
Human Oversight in Automated Dispatch
The decision to require dispatch team approval before route execution – rather than fully automated dispatch – was operationally correct. In the first three months of operation, dispatchers overrode the optimiser’s suggestions on approximately 12% of routes, typically for reasons the optimiser could not know: a customer relationship requiring a specific driver, a vehicle with a known issue, a local road event not reflected in traffic data. Over time, as the team built confidence in the system, the override rate dropped to under 4%. But the human review step was critical for building that trust during the transition period.
Logistics Platform Development: Pros and Cons of the Custom Approach
Pros
- Legacy system integration – custom development allowed direct integration with the bespoke warehouse system that no commercial TMS could accommodate without manual intervention, eliminating the core source of administrative overhead.
- Optimisation tuned to the business – the OR-Tools objective function was parameterised to prioritise vehicle utilisation over pure distance, which aligned with the client’s cost structure. Commercial platforms apply generic optimisation that may not match specific operational priorities.
- Full data ownership – all operational data remains in the client’s AWS infrastructure, supporting analytics, compliance, and future AI/ML development without vendor data access constraints.
- No per-vehicle licensing – commercial TMS platforms typically charge per vehicle or per user. The custom platform’s fixed hosting cost becomes increasingly favourable as fleet size grows.
Cons
- Higher upfront investment – the GBP 95,000 development cost is significantly higher than the first-year subscription cost of a commercial TMS, requiring a longer payback horizon.
- Ongoing maintenance responsibility – feature additions, security updates, and infrastructure management require either an ongoing development relationship or in-house engineering capability.
- Longer time to first value – twelve weeks from kickoff to production deployment versus a few weeks for a commercial platform configuration, though this is offset by the integration quality that the commercial route could not achieve.
Frequently Asked Questions: Logistics Platform Development
What route optimisation libraries are suitable for logistics platform development?
For most logistics platform development projects, OR-Tools (Google’s open-source operations research library) is the best starting point. It handles the vehicle routing problem with time windows (VRPTW), capacitated vehicle routing (CVRP), and multi-depot variants out of the box, with Python, Java, C++, and .NET bindings. The constraint programming solver performs well on problems up to approximately 1,000 stops and 50 vehicles within practical time limits. For larger problems – multi-regional operations with thousands of daily stops – commercial solvers (Gurobi, CPLEX) or specialist routing APIs (Here Routing, Google OR Fleet Routing) provide better performance at significantly higher cost. Vroom is a good open-source alternative to OR-Tools for VRPTW, with a REST API interface that is easier to integrate than OR-Tools’ programmatic API. For machine learning-based routing that learns from historical patterns rather than solving from first principles, graph neural network approaches are an active research area but not yet production-ready for most commercial applications.
How do you handle real-time route replanning in a logistics platform?
Real-time route replanning in logistics platforms must balance optimality against disruption. Fully re-optimising all routes in response to every delay would produce constantly changing instructions for drivers, creating confusion and reducing compliance. A tiered replanning approach works better in practice. Minor delays (under 15 minutes) are absorbed by adjusting estimated arrival times without changing the route sequence. Moderate delays (15-45 minutes) trigger a partial re-optimisation of the affected route only, checking whether resequencing remaining stops improves the time window compliance score without changing other drivers’ routes. Major exceptions – vehicle breakdown, large order cancellation, urgent late addition – trigger a broader replanning scope that may reassign stops between vehicles. Implement replanning as an explicit operation initiated by dispatch with a review step, rather than fully automated route changes pushed to drivers without visibility. The OR-Tools solver for partial replanning of a single route with 15-20 remaining stops runs in under 2 seconds, which is fast enough for interactive dispatch use.
What is the typical ROI timeline for a custom logistics platform development project?
For distribution and last-mile logistics operations with the characteristics described in this case study – high manual administration overhead, legacy system integration requirements, and significant vehicle utilisation headroom – custom logistics platform development projects typically achieve payback within 18 to 30 months of deployment. The payback period depends primarily on fleet size (more vehicles means more fuel and utilisation savings), current failed delivery rate (higher rates mean more redelivery cost to eliminate), and administrative overhead (more manual processes mean more labour savings from automation). For the client in this case study, the annualised cost savings of approximately GBP 380,000 against a development investment of GBP 95,000 produced payback in approximately three months – an unusually fast payback driven by the specific combination of a large fleet, high failed delivery rate, and significant administrative overhead. More typical payback periods are 12 to 24 months for projects of this type.
How do you build proof-of-delivery functionality in a logistics platform?
Proof of delivery (POD) in a modern logistics platform captures electronic evidence that a delivery was completed or attempted, sufficient to resolve customer disputes and support invoicing. The minimum viable POD implementation captures: GPS coordinates at delivery time, timestamp, delivery status (delivered, attempted, refused), recipient name or signature, and optionally a photo of the delivered goods or delivery location. In a PWA-based driver app, GPS coordinates are captured via the browser Geolocation API, photos via the camera input, and signatures via a canvas element with touch event handling. Store POD records with the delivery event and make them accessible to customer service and finance teams via the management dashboard. For high-value deliveries or regulated goods, barcode or QR code scanning of the delivery item (verifying the right item was delivered) adds an additional accuracy layer. PDF generation for POD certificates – combining delivery details, GPS map, photo, and signature – is handled server-side in Django using WeasyPrint or ReportLab, making them available for download and email delivery to customers on request.
Conclusion
The logistics platform development project described here achieved a 30% cost reduction not through a single technology breakthrough but through the systematic elimination of the manual processes, integration gaps, and optimisation inefficiencies that characterise logistics operations that have grown beyond their original tooling. The technical components – OR-Tools route optimisation, Django Channels real-time tracking, Progressive Web App driver interface – are all proven and available to any development team. The value was in assembling them correctly around the specific operational requirements of the client, with the legacy warehouse system integration quality that made the whole system coherent. That is what custom logistics platform development delivers when it is done well.
Running a logistics or distribution operation that is being held back by fragmented systems, manual processes, or a legacy TMS that cannot keep up? At Lycore, we have built logistics and supply chain platforms for distribution companies, 3PL providers, and field service operations across the UK and Europe – from route optimisation engines to real-time fleet tracking and customer-facing delivery portals. We know which parts of logistics software are genuinely complex and which parts only seem complex. Talk to our logistics software team about what your operation actually needs.
