The question is not whether the current route optimisation solver works. It is whether anyone has measured how far it now sits from the state of the art — and whether it is backed by the rest of a complete optimisation engine. Most established logistics companies already run an internal route optimisation solution, and it works. This document argues that 'it works' is the wrong test — for two separate reasons that usually apply at the same time.
Executive Summary · Two gaps that usually coexist
01The solver itself may no longer be cutting-edge
Most internal solvers are integrated once and rarely re-benchmarked afterwards, while optimisation research and AI-driven methods keep advancing — so the distance from the state of the art widens quietly, quarter after quarter. Internal solvers are typically built once, integrated, and then left alone. Optimisation research has not stood still, and AI-driven methods are now producing meaningfully better solutions on a timescale measured in quarters rather than years. A solver that was competitive at launch can fall behind without anything appearing to break.
The solver is not a complete engine
Even a strong solver is usually missing the map processing, ETA models, monitoring, analytics, feedback loops, and high-availability infrastructure that a full engine requires. A solver computes routes; an engine keeps those routes accurate, fast, and improving in daily operation. That requires map processing, ETA prediction, monitoring, analytics, a feedback loop, and high-availability infrastructure. Most internal setups have the solver and only part of the rest. The two gaps reinforce each other. Without the analytics and feedback layer of a full engine, a company has no reliable way to detect that its algorithm has fallen behind — so the shortfall is real, but invisible. This document sets out what a complete engine contains, examines the risks and advantages of using a third-party specialised provider, explains why each component is harder to build well than it appears, and proposes a staged, measurable adoption path that keeps the internal solver as a fallback.
Business challenge · Gap One
The B2B Challenge: When an Existing Solver Feels Good Enough
One of the biggest challenges in offering route optimisation technology to mid-sized and large logistics companies is that many already have an internal solution.
They have software engineers, data scientists, and optimisation algorithms that have been integrated into their operational systems over several years. Their system generates routes, supports daily deliveries, and is familiar to the organisation.
From their perspective, the obvious question is: Why should we introduce a third-party optimisation engine when our existing system already works?
This is a reasonable question. Route optimisation is often a core part of a logistics operation, and replacing or supplementing an internal engine introduces technical, commercial, and operational risks.
However, there is an important difference between having a route optimisation engine that works and having one based on cutting-edge knowledge that consistently delivers the best possible operational results. Gap One: The Solver May No Longer Be State of the Art. Most internal solvers were competitive when they were developed. The difficulty is that they are usually developed once. The hard part of an internal optimisation project is not only the algorithm itself, but also the integration: connecting to order management systems, dispatch tools, and driver apps, and earning enough operational trust that planners stop second-guessing the output. Once that work is finished and routes are flowing every morning, the solver tends to be treated as settled infrastructure rather than as a component that has to keep pace. The field, meanwhile, keeps moving quickly. Metaheuristics, clustering strategies, and learning-based methods continue to improve, and AI-driven optimisation has shortened the cycle between meaningful gains from years to quarters. A solver built a few years ago may still produce valid routes while leaving a widening performance gap in route distance and duration. None of this is visible from the outside. Routes are generated, deliveries are completed, and the operation runs. The only way to know where an internal solver actually stands is to benchmark it repeatedly against current alternatives using the company's own historical orders. In practice, this rarely happens because internal teams have other high-priority projects and responsibilities. The problem is usually not that the internal solver is bad. It is that nobody has measured it lately.
Core ideaA solver can be reliable, deeply integrated, and familiar, while still leaving considerable savings in distance, duration, fleet utilisation, and delivery capacity unrealised. Additionally, with AI-driven optimisation advancing rapidly, more efficient solutions are emerging almost every quarter.
Gap Two · Product architecture
Gap Two: A Solver Alone Is Not a Complete Engine
A solver is the mathematical core of a route optimisation system: an algorithm that takes stops, vehicles, and operational constraints as inputs and returns a set of feasible, optimised routes. In practice, it is often paired with a basic map-processing component that calculates distance and travel-time matrices between stops or retrieves this information from third-party mapping services such as Google Maps Platform or HERE Technologies. It is a well-defined, relatively self-contained piece of software, and often the first component internal teams build, because it is the most visible part of the system and delivers an immediate, tangible result.
A route optimisation engine includes not only the optimisation solver itself, but also advanced map-processing capabilities that generate, validate, and refine travel-time and distance data and, when needed, post-process or sanity-check the output of matrix services. A mature engine also typically includes ETA prediction models, analytics and performance-evaluation dashboards, monitoring and observability tools, feedback loops that continuously improve both the solver and predictive models over time, and the security, load-balancing, and high-availability infrastructure required for enterprise use.
Σ
Mathematical core
Optimisation Solver
Takes stops, vehicles, and operational constraints as inputs and returns a set of feasible, optimised routes.
- Route sequencing
- Constraint handling
- Objective optimisation
Production operating system
Optimisation Engine
Combines the solver with advanced map processing, ETA prediction, analytics, monitoring, feedback loops, security, load balancing, and high availability.
Map service Map processing ETA prediction Monitoring Feedback loop Analytics Load balancing High availability
Key difference A solver gives answers. An engine delivers reliable, measurable operational performance.
This distinction matters for the rest of this document. When we talk about benchmarking or supplementing an internal system, the question is not only whether its solver produces valid routes.
It is whether the company has a full route optimisation engine behind it, or a solver operating without the surrounding system that keeps it accurate, fast, and continuously improving.
Operational value
“Working” Does Not Necessarily Mean “Optimised”
An internal optimisation engine may successfully generate valid routes every day. It may respect basic constraints, assign deliveries to vehicles, and provide an acceptable sequence of stops.
But that does not necessarily mean it is producing the most efficient routes currently available.
1%
Small differences in route quality can have a significant financial impact at scale.A 1% improvement in distance, driving time, fleet utilisation, or delivery capacity may appear minor, but for a company handling hundreds of thousands or millions of deliveries, it can translate into substantial monthly savings.
The challenge is that these missed savings are often invisible. A company sees that deliveries are being completed successfully, but it may not know how much better the same operation could perform with a more advanced optimisation engine.
Risk assessment
The Risks of Using a Third-Party Optimisation Engine
The concerns logistics companies have about external optimisation providers are valid. They should be evaluated carefully rather than dismissed. The key question is whether each risk can be reduced through architecture, contracts, security controls, and operational fallback planning.
01
Exposure of Operational Information
Route optimisation often requires sharing operational data with an external provider. However, that does not mean the provider needs access to every detail. A practical starting point is data minimisation and pseudonymisation. For example, logistics companies can:
- Remove recipient names, phone numbers, and email addresses
- Share latitude and longitude instead of a complete address containing apartment, floor, or access details
- Use driver IDs instead of driver names
- Exclude delivery notes or other information that is not required for optimisation
- Share only the minimum time, location, vehicle, and capacity data needed to calculate the routes
Even with these measures, some broader operational information may still be exposed, including the number of deliveries completed each day, delivery volumes across cities or regions, depot and hub locations, fleet composition and vehicle capacity, and typical delivery times and operational patterns.
This information can still be commercially sensitive. It may reveal the scale of the operation, geographic priorities, capacity constraints, or recurring business patterns. Logistics companies should therefore carefully evaluate the provider’s data-processing practices, security controls and access management, data-retention and deletion policies, infrastructure and data-hosting locations, use of subcontractors, and compliance with regulations such as GDPR. Contracts should also clearly state that the provider may collect and process only the data required to perform the optimisation and may not use operational data for unrelated purposes without explicit agreement.
02
Price Changes Over Time
A provider may increase its prices after the optimisation engine has become deeply integrated into daily operations. Once a company depends on an external engine, changing providers may require technical work, testing, and operational preparation, which can reduce the customer's negotiating power.
This risk can be reduced through transparent pricing models, multi-year commercial agreements, reasonable limits on annual price increases, clear termination periods, and an internal understanding of switching costs.
The direct subscription or API price should also be compared with the operational value created. A solution that costs more but generates materially better routes may still produce a much stronger return on investment.
03
Availability of the Third-Party Service
If the external optimisation service becomes unavailable, the company may be unable to generate routes and start daily operations on time. This is particularly important for morning distribution, same-day delivery, and other time-sensitive operations.
The provider should offer suitable service-level commitments, monitoring, redundancy, incident-response procedures, and infrastructure capable of handling operational peaks.
The logistics company should also maintain a contingency plan, including the ability to use its existing solver when the external service is temporarily unavailable.
04
Dependency on the Provider
Route optimisation is not a secondary feature for many logistics companies. It may be one of the most important components of the operational platform. Depending on an external provider can therefore create concerns about long-term continuity, product direction, data portability, and the provider's financial stability.
However, dependency does not have to mean losing control. A company can place a standard internal interface between its operational platform and the optimisation engine, making it easier to switch between the external provider and an internal fallback. Clear export formats, documented APIs, and retained operational knowledge further reduce the risk of vendor lock-in.
Risk principleThe safest model is not blind replacement. It is controlled adoption, measurable benchmarking, contractual protection, and a tested fallback path.
Specialist value
The Advantages of a Specialised Optimisation Provider
Although the risks are real, the advantages can be substantial — particularly when optimisation quality directly affects cost, capacity, and service reliability.
01Access to Cutting-Edge Algorithms
A specialised provider focuses continuously on improving optimisation quality, performance, scalability, and support for complex operational constraints. Its core business is to develop better optimisation technology.
An internal team may only spend part of its time improving the solver. Even a highly capable data science team may not have the resources to follow every development in mathematical optimisation, machine learning, mapping, and large-scale computing. A specialised provider can therefore offer faster access to new methods and more advanced optimisation capabilities.
02Faster Delivery of New Features
Logistics operations evolve. A company may need support for new vehicle types, priority deliveries, driver breaks, pedestrian access, pickup-and-delivery constraints, multiple depots, dynamic orders, or more advanced time-window rules.
Developing these capabilities internally can require significant engineering, testing, and operational validation. With a third-party provider, responsibility for developing and maintaining these features is transferred to a team whose main focus is the optimisation engine. This can be especially valuable for companies with limited specialist resources.
03Fewer Conflicts With Internal Priorities
Software and data science teams inside logistics companies usually have many competing priorities. They may need to work on customer applications, warehouse integrations, driver systems, reporting, billing, platform stability, data infrastructure, and operational support.
Improving the solver may be important, but it may not always be urgent enough to receive resources every quarter. As a result, optimisation improvements can remain in the backlog for months or years. For a specialised provider, optimisation is not one item among many. Improving route quality, adding features, reducing runtime, and supporting new constraints are central product responsibilities.
04Continuous Benchmarking Becomes the Provider’s Responsibility
Determining whether a solver remains competitive requires continuous benchmarking. It is not enough to compare it against alternatives once and assume it will remain among the strongest solutions for several years.
Algorithms improve, operational requirements change, and new technologies become available. A specialised provider is responsible for testing engine versions, measuring route quality, analysing runtime, and ensuring that the solution remains competitive. Without an external provider, the logistics company must perform this work itself. In practice, many companies do not have the time or specialist resources to continuously benchmark their internal solver against the wider market.
05Map Maintenance Is Handed to the Provider
Road restrictions, new streets, access rules, turn restrictions, pedestrian paths, vehicle limitations, and travel-time estimates can all affect route quality.
Maintaining these capabilities internally can become a significant technical responsibility. A specialised provider can manage map updates, routing services, travel-time calculations, and related integrations as part of its platform, allowing the logistics company to focus more resources on its own operational and customer-facing systems.
06Less Manual Intervention, More Automation
Route quality has a direct, and often underestimated, effect on planner workload. When an engine produces high-quality, operationally practical routes, planners spend little time manually re-sequencing stops, rebalancing loads between vehicles, or fixing routes that clearly don't make sense.
When route quality is inconsistent, that manual correction becomes a daily task — and it scales with delivery volume rather than shrinking over time. A better optimisation engine reduces this burden directly: less time spent correcting routes means faster planning cycles each morning, and more staff time freed up for exceptions and customer service instead of manual re-sequencing.
TrendRoute differentiation
Why Building a Route Optimisation Engine In-House Is Hard
Building a production-grade route optimisation engine is considerably more complex than implementing an optimisation solver or integrating open-source optimisation libraries. It requires scalable map processing, reliable routing services, ETA prediction, monitoring, analytics, security, high availability, continuous benchmarking, and ongoing operational improvement.
The Solver: Optimising for What Couriers Actually Want
Open-source solvers and generic optimisation libraries provide a good starting point and are typically configured around objectives such as minimising total distance or duration. On paper, that appears to be the right objective. In practice, couriers and dispatchers may reject or manually alter routes that zig-zag, backtrack, or introduce unnecessary detours, even when the solver has found a version that is mathematically a few metres shorter. A route that looks efficient in the numbers can be harder and slower to execute in the real world.
This is why TrendRoute's solver is built around sophisticated clustering algorithms that account for delivery density and the geographical characteristics of the service area, rather than optimising purely against distance and duration. The objective is to generate a route that a courier would realistically choose to drive, not simply the shortest route on paper.
The Map Service: Corrected by Real Operations, Continuously
Base map data is not always sufficiently accurate or current for last-mile delivery. Incorrect turn restrictions, temporary construction closures, private roads, access limitations, and closed gates can all block routes that appear valid on a standard map.
TrendRoute updates and corrects its map intelligence on an ongoing basis using feedback from customer operations. Drivers and planners can identify specific streets, gates, access restrictions, and local conditions that generic map providers may not capture quickly enough.
Map Processing: Getting the Small Decisions Right
Two stops that are close together on a map are not always close together on foot, and not every stop should be reached in the same way. Deciding which stops can be treated as neighbours and served on foot, rather than by repeatedly re-parking and driving, is a modelling decision rather than a simple distance calculation.
In dense urban areas, the engine must also determine where the vehicle should stop, which nearby deliveries should form a walking tour, how that walking tour should be sequenced, and how the courier should return to the vehicle and continue efficiently towards the next driving leg. Optimising the complete operation prevents a locally attractive choice from increasing the total walking distance, the return distance to the vehicle, or the time needed to resume the driving route. The same principle applies when snapping a delivery address to the correct point on the road network, particularly near tunnels, complex junctions, large buildings, and dense areas where several streets sit close to the same address. If this step is wrong, the routing engine may direct the driver to the wrong side of a building or the wrong entrance to a complex.
Availability and Load Balancing: Built for Peak Planning Hours
Route-planning demand is not evenly distributed throughout the day. Many customers generate most of their routes within a short planning window each morning, and the engine must remain fast and reliable precisely when demand is highest.
A mature route optimisation engine should run across a cluster of nodes rather than on a single server, preferably in a cloud environment that can support dynamic load balancing during peak planning periods. This helps maintain stable planning speed and service reliability when many users within a customer organisation request routes at the same time. It is also preferable to isolate engine instances between customers. This improves security and reduces the risk that a performance issue affecting one customer’s optimisation workload will negatively impact others.
Summary So Far — And What Comes Next
A Balanced Decision Framework
Everything up to this point has been diagnosis. It is worth restating it briefly before turning to what to do about it. The two gaps: an internal solver that may no longer match the state of the art, and a solver operating without the rest of an optimisation engine around it. What a complete engine actually contains — map service, map processing, solver, ETA models, analytics dashboard, feedback loop, monitoring, and load balancing and security. The risks of depending on an external provider — data exposure, pricing, availability, and lock-in — and how each can be reduced by design rather than simply avoided. The advantages a specialised provider brings, including continuous benchmarking, faster feature delivery, map maintenance, and less manual intervention from planners. Why each component is considerably harder to build well than it looks in isolation. What follows is the practical half: a framework for deciding which responsibilities to keep in-house, a staged adoption path that never removes the internal fallback, and the questions worth putting to your own engineering and operations teams. The decision is not simply 'build versus buy'. A more useful comparison is which responsibilities the company wants to retain and which responsibilities it can transfer to a third-party provider without giving up operational resilience.
| Area | Internal route optimisation engine | External route optimisation provider |
|---|
| Control | Highest direct control over code and roadmap | Control is managed through APIs, contracts, and fallback architecture |
|---|
| Innovation speed / Continuous R&D | Depends on internal priorities and specialist capacity. Continuous R&D requires ongoing research across the solver, ETA models, map processing, feedback loops, and other engine components. | Core product team continuously develops algorithms and features. Dedicated R&D teams continuously evaluate and introduce newer methods across the complete optimisation engine. |
|---|
| Benchmarking | Must be organised and funded internally | Ongoing performance benchmarking is part of the provider’s responsibility |
|---|
| Maps and routing data | Maintained through internal or separate supplier integrations | Maintained as part of the optimisation service |
|---|
| Continuity risk | Lower external dependency, but key-person and maintenance risks remain | External dependency must be managed with SLAs and a fallback solver |
|---|
| Cost model | Internal salaries, infrastructure, and maintenance | Subscription or usage fees measured against operational savings |
|---|
Controlled implementation
A Safer Adoption Strategy
Using a third-party optimisation engine does not require a company to immediately remove its internal solution. A safer approach is to introduce the external engine gradually and make every step measurable.
- 01
Historical benchmarkRun historical orders through both systems and compare distance, route duration, vehicle count, time-window compliance, planning runtime, and operational feasibility.
- 02
Parallel operationUse the external engine alongside the internal solver on real planning days without immediately allowing it to control production.
- 03
Controlled rolloutMove selected regions, route types, or a limited percentage of daily volume to the external engine once results are consistently stronger.
- 04
Retained fallbackKeep the internal engine available and regularly test that it can still produce operationally usable routes.
- 05
Periodic reviewReassess performance, service quality, commercial terms, and security controls at agreed intervals.
Decision questions
The Right Question to Ask
The question should not simply be: 'Does our current route optimisation engine work?' In most established logistics companies, the answer will be yes.
The more important questions are:
01When did we last benchmark our solver against the best solutions currently available — not once, years ago, but recently?
02How much could we save through even a small improvement in distance, duration, or fleet utilisation?
03Do we have the full engine around the solver — map processing, ETA models, monitoring, analytics, and a feedback loop — or only part of it? Are we investing enough specialist resources to keep both the algorithm and the surrounding engine competitive?
04Do we have objective benchmark data, or are we relying on assumptions based on familiarity?
An internal route optimisation solution can provide control and stability. A specialised third-party engine can provide faster innovation, continuous benchmarking, better scalability, and access to more advanced algorithms.
For many logistics companies, the best strategy may not be choosing only one of these options. It may be using an advanced external optimisation engine as the primary solution while keeping the internal engine as a reliable fallback.
That creates a balance between innovation and control — and allows the company to evaluate optimisation based on measurable operational results rather than assumptions.
Test and compare
Benchmark Your Existing Route Optimisation Solution with TrendRoute
TrendRoute is designed to help logistics companies evaluate a specialised optimisation engine without taking an uncontrolled operational risk. Companies can introduce TrendRoute gradually, maintain clear integration boundaries, and keep their existing solver as a fallback while they validate the results.
The TrendRoute Sandbox allows teams to test routes and compare the output of their existing solver against TrendRoute using realistic delivery scenarios. This makes the discussion concrete: instead of replacing an internal system based on promises, the company can compare route quality, runtime, scalability, and constraint handling using measurable results. Explore the TrendRoute Sandbox: trendroute.ai/sandbox. Use the TrendRoute Cost Estimator at trendroute.ai/price/ to estimate the potential financial impact of improved route distance, duration, and operational efficiency.
Evaluate Route quality Runtime Scalability Constraints
The purpose is not to ask logistics companies to replace their current solution based on a sales claim. It is to give their software, data science, and operations teams a practical way to benchmark, quantify the opportunity, and make a decision based on real results.
