People who sell tradelines don’t talk about the setup much. Most of the content out there is aimed at buyers — how tradelines work, how much they cost, whether they’re worth it. But the seller side has its own logic, and once I had it figured out I realized the whole thing clicks together in a way I didn’t plan for. The most common questions I get are from buyers, but sellers are starting to find me too, and this post is for them.
Continue reading “The Full Circle: How I Set Up My Tradeline Business to Run Itself”Twenty Years of Models, One at a Time
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.

Same Three Files, Much Harder Problem
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.

Porting 1,500 Lines of C# to Python Without Losing My Mind
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”
Why Google OR-Tools and Not the Excel Solver You Already Know
The staff scheduler I wrote about a few weeks ago was a MILP — a Mixed Integer Linear Program. You define variables, constraints, and an objective function. Hand it to a solver, get an answer. Clean, relatively tractable, runs in seconds on a laptop.
The vehicle routing problem is something else entirely.

