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.
A few years ago I helped build a truck routing system for a logistics company. It was a real project — real trucks, real delivery stops, real time windows, real money. The client spent around $2 million on it. Then the pandemic hit. The project died. And the code sat on my hard drive doing nothing.
Last week I turned it into a web app.
Continue reading “The $2M Project That Died in a Pandemic (And What I Did With the Code)”
The staff scheduler took about 20 years to build.
That’s not as dramatic as it sounds. The MILP model — the math, the constraints, the logic — that came together during the Fiverr engagement described in the first post of this series. What took 20 years was accumulating enough Operations Research experience to know what the model needed to look like. The actual build, once I sat down with the problem fully understood, was fast.
The web app took a few days. The deployment took an afternoon, plus one failed attempt that taught me about gunicorn.
The app was working. On my laptop. Which is the same as not working, for most purposes.
If the goal was to keep it to myself — test it occasionally, tinker with it, update the model when I felt like it — a working local copy would be enough. But that’s not what I built it for. The point of converting these models to web apps is that they can run anywhere, for anyone, without requiring someone to have Python installed and know how to use a terminal.
So: deployment.
At some point during this project I stepped back and looked at what we’d built.
Three files. A working web application. Deployable for $7 a month. Zero web development experience going in.
That felt worth writing down.
