If you are building or scaling a 3PL platform, a fleet management product, a freight brokerage tool, or anything with "route," "track," or "match a load" in the feature list, you will hit the same five walls almost every logistics tech team hits. This post is the map of that territory: what each challenge actually is, why it is harder than it looks from the outside, and how teams that have shipped this stack before solve it. Each section links to a deeper post in this series as it ships.
Why is logistics software harder to build than typical SaaS?
Most SaaS problems are data problems: store it, query it, display it. Logistics software is a data problem wrapped around a physics problem. Trucks have real capacity, drivers have legally mandated hours, roads have real travel times that change by time of day, and a route that is optimal on paper falls apart the moment one driver calls in sick or one delivery window gets missed. The software has to reflect the real world closely enough that dispatchers trust it, and the moment it does not, they go back to a spreadsheet and a phone.
That gap between "technically correct" and "operationally trusted" is where most logistics tech projects lose months. The five challenges below are the specific places that gap opens up.
Challenge 1: Which routing engine should you build on?
Every logistics feature starts with the same question: how do you turn an address into a route, and a route into an accurate ETA? The three real options are self-hosted OSRM, Google Maps Platform, and Mapbox, and they trade off cost, accuracy, and operational burden differently.
Self-hosting OSRM on OpenStreetMap data is the cheapest option at scale and gives you full control, but you own the infrastructure, the map data refresh cycle, and the accuracy gaps in regions where OpenStreetMap coverage is thin. Google Maps Platform has the best real-world accuracy and traffic data but bills per request in a way that gets expensive fast once you are routing thousands of vehicles a day. Mapbox sits in between on both cost and control, with its own optimization and matrix APIs.
There is no universally right answer, only a right answer for your volume, your budget, and how much accuracy actually matters for your use case. A long-haul freight platform routing between distribution centers has very different needs than a last-mile delivery app navigating dense urban streets. The full comparison, including a real cost model at different vehicle-fleet sizes, is in OSRM vs Google Maps vs Mapbox: choosing a routing engine for logistics platforms.
Challenge 2: How do you optimize routes at real fleet scale?
Picking a routing engine gets you point-to-point directions. It does not solve the actual problem: given 40 stops, 6 vehicles, delivery time windows, vehicle capacity, and driver hour limits, what is the best assignment of stops to vehicles and order of stops per vehicle? That is the Vehicle Routing Problem (VRP), a well-studied but genuinely hard optimization problem, and it is where most teams either underbuild (a naive nearest-neighbor heuristic that looks fine on 10 stops and falls apart on 200) or overbuild (reaching for a full commercial solver when an open-source library like Google OR-Tools or VROOM would have shipped in a third of the time).
The constraints are what make this specific to your business. Time windows, vehicle capacity, driver hour limits, multi-depot assignment, and priority stops all change which approach fits. Post 3 in this series covers the actual algorithm choices and a build-vs-buy framework for this layer specifically.
Challenge 3: How do you reduce empty miles with backhauling?
Every mile a truck drives empty is a mile that costs money and earns nothing. Backhauling, matching an outbound load with an available return load, is one of the highest-leverage features a freight or 3PL platform can build, and it is also one of the most data-hungry. Good matching needs lane history, real-time capacity data, deadhead cost calculation, and increasingly, AI agents that can proactively reach out to carriers or brokers when a match appears rather than waiting for someone to search for one.
Teams that get this wrong usually built the matching logic before they had the data pipeline to feed it well, or built a UI for dispatchers to search manually instead of a system that surfaces matches automatically. Post 4 covers what the matching logic actually needs and where automation genuinely helps versus where it just adds noise.
Challenge 4: How do you track vehicles in real time without the system falling over?
Real-time location tracking sounds simple until you are ingesting GPS pings from hundreds or thousands of vehicles, computing geofence entry and exit events, predicting ETAs that update as conditions change, and doing all of it without your database falling over under write volume or your mobile app draining a driver's phone battery in four hours. This is a streaming and infrastructure problem as much as it is a logistics problem, and the architecture that works at 50 vehicles usually does not work at 5,000.
Add ELD (Electronic Logging Device) and telematics integration on top, systems that were mostly built for compliance reporting, not real-time streaming, and you have a genuinely hard systems design problem. Post 5 in this series covers the ingestion pipeline, geofencing approach, and ETA prediction architecture that holds up at scale.
Challenge 5: How do you integrate with legacy TMS and dispatch systems?
Almost no logistics tech project starts from a blank slate. There is an existing TMS (Transportation Management System), a dispatch tool the ops team already trusts, and often a patchwork of spreadsheets filling the gaps between them. New software has to integrate with that reality, not replace it overnight, or it gets rejected by the people who actually run daily operations regardless of how good the underlying engineering is.
This is less a technology problem and more a sequencing and change-management problem, but it shows up as engineering work: building adapters for systems with poor or nonexistent APIs, running old and new systems in parallel during a transition, and designing the new system to earn trust incrementally rather than asking dispatchers to switch cold. It is the challenge most likely to sink a project that gets the routing and optimization exactly right on paper.
Should you build this in-house or bring in specialists?
The honest answer depends on how central logistics is to what you are building. If route optimization, tracking, or matching is a core product feature, not a bolted-on capability, it is worth having engineers on the team who have shipped this specific kind of system before. The failure modes here (a VRP solver that times out past 200 stops, a tracking pipeline that cannot handle a fleet doubling in six months, a TMS integration that breaks every time the vendor changes their export format) are domain-specific in a way that generalist backend experience does not fully prepare you for.
Where we see this work well: a small core team with deep geospatial and logistics-systems experience, paired with a broader engineering team for the rest of the product. Our automation consultants scope this kind of build regularly, and for the workflow and dispatch-automation side specifically, AI workflow automation for fleet companies is the companion read on what to automate first once the core platform is in place.
What is in the rest of this series?
This post is the map. The next four go deep on each challenge:
- OSRM vs Google Maps vs Mapbox: choosing a routing engine for logistics platforms
- How route optimization actually works for 3PL and fleet platforms
- Backhauling and load matching: how to cut empty miles with smart software
- Real-time location tracking architecture for logistics platforms
Each one gets linked here as it ships. If you are scoping a logistics or 3PL build right now and do not want to wait for the series, talk to us, this is exactly the kind of architecture decision our automation consulting engagements are built around.
Final word
Logistics tech looks like a mapping problem from the outside and turns out to be an optimization, streaming infrastructure, and change-management problem once you are actually building it. The five challenges above are not exotic, they show up on nearly every 3PL and fleet platform we have seen, and every one of them has a well-understood solution once you know which pattern fits your scale and constraints. The rest of this series is that detail, one challenge at a time.