Show IH: I Built a Deterministic MDVRP Engine That Solves a 10,000-Customer Routing Problem on an Android Phone
A few weeks ago I shared the VRPTW engine.
Today I'd like to share another routing module inside GSL Solver.
This one focuses on the Multi-Depot Vehicle Routing Problem (MDVRP).
Again...
Still no research lab.
Still no VC funding.
Still no high-end server.
Just a logistics worker in Bangkok building deterministic routing systems on an Android phone.
The Problem
MDVRP becomes increasingly difficult as multiple depots, fleet allocation and capacity constraints interact across large customer networks.
Most published work evaluates public benchmark libraries.
I also wanted to know:
How far could a deterministic architecture scale beyond those benchmarks?
What I Built
A deterministic MDVRP engine
designed around:
• Zero stochastic variance
• Zero per-instance parameter tuning
• Same input → same output
• Mobile-first execution
Public Benchmark Results
The engine completed the classical Cordeau benchmark library:
✅ p-series (23 instances)
✅ pr-series (10 instances)
33 public benchmark instances
Across all published benchmarks:
• 100% feasible solutions
• Capacity verified
• Fleet verified
• Complete customer coverage
verified
Stress Test
Beyond public benchmarks, I generated an internal routing
instance containing:
• 10,000 customers
• 100 depots
Results:
• Fully feasible solution
• 1,371 vehicles
• Routing cost: 184,752.27
• Runtime: 8.91 seconds
—all executed on an Android phone.
The Bigger Idea
I don't believe every routing problem requires increasingly larger hardware.
Sometimes improving the optimization architecture itself can matter just as much.
This MDVRP engine is another step toward that goal.
🌐 https://gsl-solver.com
Repository:
This is seriously impressive work — especially the part about building deterministic routing systems on an Android phone. Most people assume you need a lab, a cluster, or VC money to touch problems at this scale, but you’re proving the opposite.
I’ve been working on a heavy‑load engine myself, and seeing someone else push boundaries with pure determination hits hard. The multi‑depot angle is no joke — getting stable performance across thousands of customers is something even funded teams struggle with.
Respect for showing what’s possible without the “standard setup.” This is the kind of build that reminds founders what grit actually looks like.
Thank you, I really appreciate that.
One of my goals with GSL has always been to show that meaningful optimization research doesn't necessarily require expensive infrastructure.
Of course, larger hardware has its place, but I wanted to see how far careful algorithm design and deterministic architecture could go first.
I'm glad that idea came across. Best of luck with your heavy-load engine as well—I look forward to seeing where you take it.
What stood out to me wasn't the benchmark numbers—it was the idea that improving the optimization architecture can be a bigger lever than scaling hardware.
Most routing engines compete by showing they can solve larger problems. You're making a different argument: that deterministic design changes what's possible on ordinary hardware. That feels like the more distinctive story, because it's a strategic choice about how the system is built, not just another performance claim.
Thank you. That's exactly the direction I wanted to explore.
Hardware will continue to improve, but I believe optimization architecture deserves just as much attention. My goal with GSL has never been to compete on hardware scale alone, but to see how far a deterministic architecture can go while remaining practical, reproducible, and deployable on ordinary devices.
I'm glad that idea came across.
Interesting.
Reading your reply made me think less about deterministic optimization itself and more about what the product quietly commits itself to once architecture becomes the primary source of advantage instead of raw compute.
I don't think I can explain that line of reasoning properly in a thread without oversimplifying it.
If you're interested, what's the best email to reach you on?
Thanks, Aryan. I appreciate you reaching out.
I remember our earlier conversations about infrastructure positioning and branding, and I agree this is probably a discussion that's better suited for email than a comment thread.
You can reach me at:
ctsuwan@proton.me
I'd be interested to hear your perspective on the architectural implications you're referring to.
Looking forward to the conversation.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
8.91 seconds for 10,000 customers across 100 depots on a phone is a genuinely strange flex in a good way, most people would reach for a cluster before questioning whether the architecture even needed one. The determinism point is the part I'd push on hardest in your position: for routing specifically, same-input-same-output is a sales feature, not just an engineering nicety, since ops managers get burned constantly by solvers that quietly give a different answer on rerun and can't explain why. Have you found dispatchers trust the output more once they learn it's reproducible, or does nobody ask until something breaks?
Thank you. I think reproducibility becomes valuable before optimization quality is even discussed.
At the moment, GSL is still in its early commercial stage, so I don't yet have a large deployment base to measure dispatcher behavior objectively.
However, my motivation came from practical logistics work. When the same data produces different plans on repeated runs, it becomes difficult to audit decisions, explain changes, or compare operational scenarios. That's why I chose a deterministic architecture from the beginning.
My goal isn't to claim that determinism is always better than stochastic search, but to offer an alternative where repeatability, auditability, and consistent decision-making are first-class design principles.