Logistics software is an integration problem wearing a UI.

Carrier API integration looks trivial until you compare a quote with an invoice. FedEx, UPS and DHL each expose rate, label and tracking endpoints with their own OAuth lifecycles, their own address models and their own opinion about what counts as residential. Address validation is the quiet killer. A normalisation that silently reclassifies a commercial address as residential adds a surcharge you never quoted, and it doesn’t return an error while doing it. Dimensional weight does the rest, since billable weight is the greater of actual weight and volume divided by the dimensional divisor in your contract, 139 being the common US domestic figure. Add address correction fees, liftgate, delivery area and fuel surcharges, and the gap between what you charged the customer and what the carrier billed you becomes a monthly reconciliation job. Design for it on day one rather than bolting it on in month six.

Label generation deserves the same respect. Creating a label is a financial event rather than a PDF render. Once it’s manifested the carrier can bill it whether or not the parcel ever moves, void windows are finite, and a naive retry loop that generates duplicates on timeout costs real money before anyone notices. Idempotency keys on every rate and ship call, and a stored carrier response for every label, are not optional here.

On the warehouse side the first question is which system owns what. A WMS owns location-level stock, licence plates, putaway and pick paths. An ERP owns the financial value of inventory and the purchase and sales orders. Your application usually owns the promise you made to a customer, and that’s the only one of the three you should store as truth. Writing directly into a WMS database is a decision you regret at the first vendor upgrade, when your inserts bypass the triggers maintaining their allocation tables and you discover the support contract no longer covers you.

Then the data-model problem this vertical owns outright. Inventory is an eventually-consistent number rather than a fact. On-hand, allocated, available-to-promise and in-transit are four different quantities that disagree at any given second. Soft reservations expire, hard allocations don’t, cycle counts reconcile against a physical reality neither system observed, and a picker who can’t find a case creates a short-ship that has to unwind an allocation, a customer promise and possibly a payment. Model reservations explicitly with expiry, keep an event log of every quantity change, and never expose a single integer called stock to your checkout.

What you’re asking for is the vehicle routing problem with time windows and capacity constraints. It generalises the travelling salesman problem, it’s NP-hard, and exact methods stop being practical well below the size of a real urban fleet. You’re running a heuristic either way. The question is which one, and what it costs you.

In practice: a Clarke-Wright savings or cheapest-insertion pass to reach a feasible plan quickly, then local search with 2-opt, Or-opt, relocate and swap moves, then a metaheuristic such as large neighbourhood search or guided local search if you can afford the runtime. Google OR-Tools covers most of that without anyone writing a solver. The tradeoff is blunt. Five seconds of search and five minutes of search usually differ by a few percent of distance, and dispatchers care far more about a plan that stays stable between runs than about those few percent.

Two things sink these projects. First, the travel-time matrix. Five hundred stops means 250,000 pairs, and live traffic matrix calls are typically the largest running cost in the whole feature, so cache aggressively and batch. Second, the objective function. Optimising pure distance produces routes drivers refuse to run. The real objective mixes driver hours and overtime, missed-window penalties, vehicle access limits and territory familiarity, and tuning those weights against your own historical days is the work that decides whether anybody uses the output.