Show IH: GSL Solver — A deterministic vehicle routing engine I built entirely on an Android phone.
Over the past few months I've been quietly working on something much larger than a single routing algorithm.
Today I've finished publishing the first complete public benchmark portfolio for Geo Strategy Logistic (GSL) Solver, covering four major Vehicle Routing Problem families:
✅ CVRP
✅ VRPTW
✅ MDVRP
✅ MDVRPTW
The public benchmark portfolio includes more than 10,800 evaluated routing instances, ranging from classical academic benchmarks to large-scale stress tests.
Everything follows exactly the same philosophy:
• Deterministic optimization
• Zero per-instance tuning
• Reproducible execution
• No stochastic search
• Mobile-first development
One part I'm personally proud of is that the entire framework was developed and benchmarked using only an Android phone running Python through Pydroid 3.
No workstation.
No GPU cluster.
No cloud compute.
Just a phone.
I know that's not the normal way people build optimization software—but it forced me to design algorithms that are computationally efficient instead of relying on increasingly larger hardware.
There is still plenty of work ahead, but completing the first public benchmark portfolio feels like an important milestone.
I'd genuinely appreciate any feedback from people working in optimization, logistics, or operations research.
🌐 Research page
https://gsl-solver.com/research
Building something like this entirely on an Android phone is a great founder story.
The interesting challenge after building a technically impressive product is making sure the people who need it understand the value without needing to understand all the engineering behind it.
A vehicle routing engine solves a very real business problem, but most customers aren't thinking "I need a deterministic routing algorithm." They're thinking:
"How do I reduce delivery costs?"
"How do I plan more efficient routes?"
"How do I save hours every week?"
The technical achievement gets attention, but the business outcome is what gets someone interested enough to try it.
Making that connection obvious on the homepage is usually where great tools turn into products people actually adopt.
Thanks, I really appreciate this perspective.
You're absolutely right. Building the technology and communicating its business value are two very different skills.
The benchmark portfolio itself has actually been completed for some time. What I'm doing now is gradually publishing the results and building a public technical record before shifting more attention toward the product and business side.
To be honest, I naturally enjoy building and validating systems much more than marketing them. Engineering feels comfortable; communicating value to customers is something I'm still learning every day.
Comments like yours are genuinely helpful because they remind me that a good technology alone isn't enough—people need to immediately understand how it solves their problems.
So thank you. I'll definitely keep that in mind as GSL continues to evolve.
For anyone interested in the technical details, benchmark reports, and public research artifacts, I've organized everything into a single portfolio here:
https://github.com/CT1-deMo-goG/AI-Research-Portfolio/tree/64920c94479af64259767266c3fab7a1e9369b21/gsl
Since my Render-hosted research page is currently offline, this GitHub portfolio now serves as the central entry point for the complete GSL (Geo Strategy Logistic) documentation, benchmark reports, repositories, and technical references.
built and benchmarked 10,800 instances on a phone in pydroid. i had to read that twice.
you say the constraint pushed you toward deterministic instead of stochastic search. i'm curious about the boring side of it: how long did a full benchmark run take, and did the phone ever just die mid-run? the failure modes of building somewhere weird are the part nobody ever writes about.
Thanks! 😄
Surprisingly, the phone itself never failed during a benchmark campaign.
My workflow was fairly simple: I never launched everything blindly. I first tested individual instances, then ran each benchmark family as a separate batch while monitoring execution time and memory behavior. If I noticed anything unusual, I stopped immediately, optimized the engine, and started again.
The "zero-tuning" part also deserves a bit of explanation. It doesn't mean I skipped engineering work. Most of that effort happened upfront: making sure the input parser could correctly handle every data format within a benchmark family before running the full batch. That initial stage involved plenty of refinement, but once the parser consistently handled the entire dataset, the rest of the benchmark campaign became mostly a matter of letting it run and collecting the results—without instance-specific parameter tuning.
Most batches ended up running very smoothly. The largest one was a batch of 10,000 XML benchmark instances, which completed successfully and generated all 10,000 solution files.
Looking back, I think one reason for that stability is that I didn't build the engine on top of large optimization libraries. Since I implemented the algorithms from scratch, I had complete control over memory usage, execution flow, and every optimization decision. On resource-constrained hardware like an Android phone, that level of control turned out to be extremely valuable.
In a strange way, the hardware limitations forced me to become a better algorithm designer rather than relying on more computing power.
The "built entirely on a phone, which forced computational efficiency instead of throwing hardware at it" story is genuinely compelling, and it's not just a fun fact, it's a real technical differentiator. Deterministic, zero per-instance tuning, no stochastic search, reproducible: that's a specific and defensible position in a field crowded with metaheuristics that need tuning and get non-reproducible results. The constraint produced the moat. Lead with that harder.
Honest read on where this goes next, since you asked: you've built a serious credibility asset (10,800 instances is a real portfolio, not a toy), but a benchmark portfolio is proof, not a product. The gap between "my solver is provably good" and "someone pays for this" is entirely about who feels the pain and how they'd consume it. Right now it's framed for the OR/academic audience who'll appreciate the benchmarks, but that audience mostly doesn't buy, they cite. The people who pay for routing (logistics ops, last-mile delivery, field service dispatch) don't read benchmark tables, they ask "does it cut my fuel/time cost and does it plug into my stack."
So the strategic fork worth naming now: is GSL a research credential you're building toward a job/consulting/licensing, or a product you're taking to logistics buyers? Those need completely different next moves. If it's the latter, the determinism-and-reproducibility angle is actually a killer enterprise selling point (ops teams hate that their current routing gives different answers each run), but it has to be translated out of OR language into "same input, same route, every time, auditable."
The benchmark work is the hard part and you've done it. The question is which audience the next artifact is for.
Who's the intended buyer or beneficiary, an employer, a logistics company, other developers licensing the engine? That decides whether the next thing you build is a paper, an API, or a case study.
Thank you — this is probably one of the most thoughtful pieces of feedback I've received on the project.
You're absolutely right that benchmarking proves capability, but not necessarily product-market fit.
My long-term direction is toward enterprise logistics rather than academia. The benchmark portfolio was intended as a public technical foundation to establish reproducibility and engineering credibility before moving further into commercial deployment.
I also agree that deterministic execution needs to be translated into business language rather than optimization terminology. "Same input, same route, every time" is probably a much stronger message for operations teams than talking about deterministic algorithms.
Thanks again for taking the time to write such detailed feedback.
Enterprise logistics is the right call, and now that the direction is set, the sharpest next move is to pick the one vertical where determinism isn't just nice but non-negotiable, because "same route every time" is worth wildly different amounts to different operations.
The distinction that matters commercially: for a lot of routing buyers, a stochastic solver that's 3% better on average is fine, they don't care that it varies run to run. But some operations need reproducibility as the whole game: anything audited or regulated (pharma cold-chain, hazmat, medical courier), anything with SLA penalties where you must prove why a route was chosen, anything where dispatchers stop trusting a system that answers differently to the same inputs and start overriding it. There, "auditable, same input same route" isn't a feature, it's a compliance and trust requirement your stochastic competitors structurally can't meet. That's your beachhead, not "logistics" broadly.
The trap otherwise: enterprise logistics is dominated by entrenched players (Routific, OptimoRoute, the big TMS suites) competing on integrations and features, and a new solver competing there on "better optimization" loses on everything except the algorithm. But "the only routing engine that gives auditable, identical results every run," in a vertical that legally or operationally needs that, you're not the 11th routing tool, you're the only one solving their specific problem. Same engine, uncontested niche.
So the next artifact isn't a general API, it's one case study in one reproducibility-critical vertical: "here's a regulated courier operation, here's what non-deterministic routing cost them in audit/trust/overrides, here's the before/after." One concrete story in the right niche opens more doors than 10,800 instances.
Figuring out which vertical to plant that flag in, and how to frame determinism as their must-have not your spec, is exactly the positioning work I spend my time on, part of the team building Hivemind, an AI strategy copilot. If you want to pressure-test the beachhead choice before committing: https://hivemind.myosin.xyz. Either way, narrow to the niche that can't live without reproducibility, that's where you win uncontested.
One interesting thing I discovered while building GSL is how quickly Vehicle Routing Problems become computationally difficult.
VRP belongs to the family of NP-hard optimization problems, where the number of possible routing combinations grows explosively as customers increase.
Ironically, I never used existing routing libraries—not because I thought they were bad, but because I simply didn't know how to use them when I started.
So I ended up building the optimization algorithms from scratch.
Sometimes not knowing the "standard way" forces you to explore a completely different one.
More benchmark reports, execution logs, and technical details are available here:
https://gsl-solver.com/research