Personal blog on early retirement, selling tradelines, and analytics projects. I write about what I learn as I am learning it.
If you’ve tried to get a straight price out of Route4Me, you’ve probably hit a “contact sales” button instead of a number. That’s the most common complaint I hear, and it’s usually why people start searching for a route4me alternative in the first place. I’ve spent twenty-plus years building routing and scheduling optimization for a living, so I built a free one for the operator who just wants to run a route, not book a demo call first.
I spent twenty-plus years building vehicle routing models for companies that paid serious money for them, so when I went looking at RouteXL alternatives recently, I wasn’t shopping — I was checking out the neighborhood. RouteXL is probably the best-known free multi-stop route planner on the internet, and for good reason: paste in your addresses, get them back in a sensible order, free up to 20 stops. But 20 stops is exactly where a lot of real delivery days start, and that’s where the free tier ends. This post is an honest tour of what’s out there — including the free VRP tool I built and run myself — and which one fits which kind of routing problem.
I’ve been doing operations research for over 20 years. Most of what I’ve built is locked inside Excel files on a hard drive. Not because Excel is where OR models belong — it isn’t, really — but because that’s where the data was, that’s where the clients were, and that’s what worked at the time.
The backlog is real. Staff scheduling, vehicle routing, warehouse slotting, least-cost formulation, a few others. Each one took months to build and calibrate. Each one is doing nothing right now except existing as a .xlsm file.
When I finished porting the routing engine to Python, I had a 480-line file that solved vehicle routing problems and printed results to a terminal. That’s useful exactly to me, in exactly one context. The staff scheduler had already gone through the same transition — terminal script to Flask web app — and I’d figured out the pattern there. So I assumed wrapping the VRP would be roughly the same amount of work.
It wasn’t the same amount of work. But the structure was.
The original routing model was 1,500 lines of C#. The Python port ended up around 480 lines. Some of that compression is the language — Python is more concise. Some of it is that I stripped out the proprietary cloud backend, the database calls, and the dispatch interface. What remained was the core: the model structure, the constraints, the solver parameters.
The translation itself was mostly mechanical. OR-Tools has Python bindings that mirror the C# API closely enough that you’re often just changing syntax: camelCase to snake_case, semicolons disappear, type declarations disappear. But “mostly mechanical” left room for a few things that didn’t work the first time.
Continue reading “Porting 1,500 Lines of C# to Python Without Losing My Mind”