Show IH:From Bangkok Driver to a Full 10,000-Node Benchmark 🚀
I'm not a researcher.
I don't have a lab.
I don't have a team.
I'm a logistics guy from Bangkok who got frustrated watching route planning software fail in real-world operations — wrong constraints, unstable outputs, and solutions that looked good on paper but broke down in practice.
So I built my own engine. Alone. On a single Android phone.
Today, I'm releasing the 2026 GSL Benchmark Report.
What I built
GSL Engine — a deterministic VRP framework covering:
CVRP
VRPTW
MDVRP
MDVRPTW
No stochastic drift.
No parameter tuning.
Same input → same output.
Benchmark coverage
Set X — 100 to 1,000 nodes
Set XL — 1,000 to 10,000+ nodes
Every result was validated using the official CVRPLib / PUC-Rio checker.
✅ X-n101-k25 → Feasible
✅ X-n1001-k43 → Feasible (~4.8s)
✅ XL-n9571-k55 → Feasible
✅ XL-n10001-k1570 → Feasible
Not cherry-picked instances. Full benchmark coverage.
Repositories
📊 Set X:
https://github.com/CT1-deMo-goG/GSL-CVRP-SetX
📈 Set XL:
https://github.com/CT1-deMo-goG/GSL-CVRP-SetXL
Why this matters
Most discussion around large-scale VRP focuses on stochastic search and massive compute infrastructure.
My work explores a different direction: whether a fully deterministic architecture can remain scalable, reproducible, and operationally stable — even at very large benchmark scales.
Still early. Still evolving.
But the full benchmark now exists.
One thing I learned while building this:
In real logistics operations, reproducibility matters more than many benchmark discussions acknowledge.
A route that changes unpredictably between runs can create operational instability even when the objective score looks good mathematically.
That became one of the main reasons I focused heavily on deterministic architecture.
This is stronger than a benchmark post. The real angle is operational stability. Route planning tools often look good in controlled tests, but logistics buyers care about whether the output stays feasible, reproducible, and usable when real constraints get messy.
The deterministic part is important because “same input, same output” is a trust signal for operations teams. It makes the engine feel less like an academic optimizer and more like infrastructure that can be audited, compared, and deployed in real workflows.
One thing I’d think about early is the GSL name. It works for a solver/project, but if this becomes serious logistics optimization infrastructure, Davoq.com would give it a harder, more enterprise-grade systems brand than a technical acronym.
Thanks for the suggestion! GSL stands for Geo-Strategy Logistic — the name is intentional and already has traction. gsl-solver.com is live and indexed. Rebranding isn't on the roadmap right now, but appreciate the enterprise angle you pointed out around operational stability. That's exactly the direction we're building toward.
That makes sense.
And I agree traction/indexing matters more than aesthetics at this stage.
The only thing I’d pressure-test is whether GSL keeps the product mentally framed as “a logistics solver project” even as the actual value becomes operational infrastructure.
Because the direction you described is much bigger than route optimization itself.
Deterministic output, reproducibility, auditability, and constraint stability are the kinds of things enterprise operations teams associate with infrastructure they can trust, not just optimization software.
That gap matters because buyers often decide the category before they evaluate the engine.
So I would not force a rebrand early. But I’d keep watching whether the acronym is helping the product feel deployable and enterprise-grade, or quietly keeping it in the “technical solver/tool” bucket while the product grows beyond that.
That's a sharp distinction — and honestly one I've been actively navigating.
The engine is already being positioned as LaaS (Logistics as a Service) on the product side, which is very much the infrastructure framing rather than just a standalone solver.
The GSL name stays for now, but you're absolutely right that the broader category play is intentionally bigger than “route optimization software.”
At the same time, I also want to stay grounded and focused on proving the architecture through real operational logistics problems first before trying to expand the vision further.
I really appreciate how clearly you articulated the gap between “technical solver” perception and “operational infrastructure” perception. As someone still learning the industry side of all this, I'd genuinely value any advice or perspective you think is worth pressure-testing early.
That makes sense.
If you’re already thinking in terms of LaaS, then the key thing I’d pressure-test early is not just the engine. It is what buyers believe they are adopting.
A solver sounds like something they test.
Infrastructure sounds like something they depend on.
That distinction matters in logistics because buyers are not only asking “does the route improve?” They are asking whether the system is stable enough to trust inside real operations, with messy constraints, repeatable outputs, auditability, and fallback paths.
So I’d keep GSL for now if it has traction, but I’d be careful about letting the acronym carry the whole category.
GSL Solver may be useful for technical clarity, but LaaS needs to feel bigger than a solver. It needs to feel like an operational layer.
The thing I’d watch in early conversations is this:
Do buyers describe it as “your solver,” or do they describe it as “the logistics layer we can rely on”?
If it is the second, the naming and brand architecture may need to mature before the product gets too locked into the technical-tool frame.
That distinction is genuinely valuable — especially the difference between something organizations “test” versus something they eventually “depend on.”
I think you're absolutely right that category framing can shape buyer perception long before they evaluate the underlying architecture itself.
Right now I'm intentionally focused on proving reliability and operational trust through real logistics workflows first, which is why the product positioning is still very grounded around routing and LaaS adoption.
But your point about avoiding an accidental “technical tool” framing definitely resonates with me, especially as the system evolves beyond just solving routes.
Really appreciate the depth of this perspective.
Exactly. Proving reliability first is the right order.
The thing I’d keep separate is product proof vs category lock-in.
You can prove the architecture through grounded routing workflows while still watching whether the market is mentally placing GSL in the solver bucket or the infrastructure bucket.
That matters because once buyers start repeating “solver,” it can become harder to move the product into LaaS / operational layer territory later, even if the system itself has grown beyond that.
So I’d treat early conversations almost like category research:
What do they trust?
What do they hesitate on?
What word do they use after the demo?
Do they talk about better routes, or operational reliability?
That language will tell you when the brand architecture needs to mature.
Happy to stay connected on LinkedIn if useful. This kind of solver-to-infrastructure shift is exactly the kind of naming/category transition worth tracking early:
https://www.linkedin.com/in/aryan-y-0163b0278/
That’s an incredibly valuable distinction — especially separating product proof from category lock-in.
I think you’re right that the language people naturally use after interacting with the system will probably reveal more than direct feedback forms ever could.
Up to now I’ve been heavily focused on proving operational reliability and usability, but this conversation genuinely changed how I think about early customer interactions and positioning signals.
I really appreciate the depth of perspective here — and absolutely happy to stay connected on LinkedIn as GSL continues evolving.
Appreciate that. And yes, I think the real signal will come from buyer language, not just product feedback.
If customers start describing GSL as something they “depend on” rather than something they “test,” that’s when the category shift becomes real. At that point, the brand architecture matters more because the product is no longer just proving routes, it is shaping how logistics teams trust the operational layer.
Feel free to send me a connection request on LinkedIn. Happy to stay connected and follow how this evolves, especially because this solver-to-infrastructure shift is exactly where the naming/category question becomes more important once the market starts pulling the product upward.
Really appreciate the insight throughout this discussion — it genuinely shifted how I think about positioning and category evolution around GSL.
I already sent a LinkedIn connection request from this profile in case it helps identify me more easily:
https://www.linkedin.com/in/ctsuwan
Looking forward to staying connected and seeing where this solver-to-infrastructure transition goes over time.
A behind-the-scenes reality of a solo creator: Crunching the numbers on this raw log, the net runtime for Set XL alone took exactly 17 hours and 15 minutes of continuous processing on my phone. In reality, my device was completely bricked for nearly 24 hours straight just to finish the whole run without the Android OS killing the process. 😅
The funniest part? I couldn't touch my phone all day, so I had to hijack my 7-year-old daughter's phone—an ancient 9-year-old device from 2017—just to watch cartoons and pass the time while checking on my benchmark. That's when I snapped the photo of my setup.
Right now, gsl-solver.com is live as a direct web-based solver. I deliberately designed it to be simple: you just paste your input dataset and get the optimized, stable output directly right on the page, without any integration overhead.
If you're dealing with routing nightmares, feel free to test your instances directly on the site. Would love to get your feedback on the web solver experience!