← Work
2025-07
Cross-Border Fleet Optimizer
A super-opinionated GPS for a tiny cross-border fleet, optimized for cost not just distance.
logisticspythonoptimization
Reality check: not a full TMS. But it already plans better than a stressed human with Google Maps, a whiteboard, and vibes.
Quick scan
What it is A Python tool that plans multi-truck routes with demand and time windows, outputs a route plan and a map, and minimizes total cost (distance + driver time) rather than pure kilometers.
Why it matters Border logistics is huge and weirdly low-tech. Humans are forced to do combinatorial planning manually, under stress, with poor cost visibility.
Payoff Once cost + real travel times were wired in, the tool started making non-obvious but believable decisions (longer distance, cheaper total cost). That’s when it became a real tool.
What this actually is
You give it a depot, a set of cities, demand per city, and simple delivery windows.
It outputs: which stops each truck visits, the order, rough arrival timing, and a map that makes the day obvious.
It’s meant for the person planning routes with a whiteboard, Google Maps, and intuition.
Why I bothered to build it
Humans are bad at this class of problems: too many combinations, messy constraints, and tradeoffs between time, distance, and cost.
I wanted to see if I could build something that plans better than a human while still being simple enough to trust.
What actually worked
- Cost-based routing produced good non-obvious routes (not just shortest distance).
- Switching from straight-line distances to real road data changed everything.
- One-command scenario runs made testing fast (CSV in → plan out).
- Map output tells the story faster than any table.
What is still janky
- Texas routes are real (OSRM). Mexico side still has approximation gaps depending on coverage.
- Cost model is simple (flat per-km + per-hour; no tolls, overtime, fuel differences).
- Time windows are hard constraints; no ‘least bad’ soft penalties yet.
- Setup is not dispatcher-friendly (Docker + OSRM + patience).
What I would do next
- Full-region routing data for true cross-border realism.
- Richer cost model (overtime, tolls, country-specific fuel).
- Soft time-window penalties (late at a cost instead of solver failure).
- Simple web UI (upload CSV → run → map + report download).
Technical appendix
- Problem type: CVRPTW (Capacitated Vehicle Routing Problem with Time Windows)
- Language: Python
- Libraries: pandas (data), OR-Tools (routing), folium (maps), geopy (fallback distances)
- Routing: local OSRM in Docker for realistic travel times/distances; straight-line fallback when needed
- Objective: minimize total cost = distance × cost_per_km + time × cost_per_hour
- Design detail: routing logic separated so OSRM can be swapped without touching optimization core; timestamped outputs for traceability
← Back to Work