u/Tight_Cow_5438

Hey guys,

I’m drafting a post about structural scalability in optimization algorithms. Most routing systems (VRP solvers) I’ve worked with require massive centralized infrastructure or heavy memory footprints to avoid crashing under massive production workloads.

I wanted to prove that high-volume routing is an architectural challenge, not an infrastructure dependency. So I ran the MIT-Amazon Last-Mile dataset on a 4GB Raspberry Pi 400.

The engine managed to plan the 1,048,575 stops across 17 depots in about 8 hours on a single 1.3GB RAM footprint, maintaining identical route quality metrics to my MacBook M4 benchmarks (just ~18x slower due to clock/IO limits)

From a system architecture perspective, do you think highlighting low-cost node horizontal scaling changes the conversation regarding legacy API business models?

Hey guys,

I’m drafting a post about structural scalability in optimization algorithms. Most routing systems (VRP solvers) I’ve worked with require massive centralized infrastructure or heavy memory footprints to avoid crashing under massive production workloads.

I wanted to prove that high-volume routing is an architectural challenge, not an infrastructure dependency. So I ran the MIT-Amazon Last-Mile dataset on a 4GB Raspberry Pi 400.

The engine managed to plan the 1,048,575 stops across 17 depots in about 8 hours on a single 1.3GB RAM footprint, maintaining identical route quality metrics to my MacBook M4 benchmarks (just ~18x slower due to clock/IO limits)

From a system architecture perspective, do you think highlighting low-cost node horizontal scaling changes the conversation regarding legacy API business models?

I’m building a niche B2B API for last-mile route optimization and I’m struggling with pricing/packaging.

The product takes delivery stops, vehicles, package data, capacity limits, time windows, and route constraints, then returns a full fleet plan.

The tricky part is that usage can vary a lot:

- small customer: hundreds or a few thousand stops per day
- medium customer: ~10K stops/day
- enterprise customer: tens or hundreds of thousands of stops
- extreme cases: up to ~1M stops in one planning job

The API is compute-heavy, but the value is also tied to cost reduction: fewer routes, less distance, better fleet utilization.

Right now I’m considering a per-optimized-stop pricing model.

My concern is that “per stop” is easy to understand, but might feel too variable for enterprise buyers. Monthly tiers are easier to sell, but can be hard to align with compute cost.

Demo pricing:
https://demo.vepathos.com/pricing

For founders selling B2B APIs or infrastructure:
how would you price this?

does this type of pricing feel competitive, too expensive, or too cheap compared to how routing/dispatch tools are usually priced?

Most large-scale routing systems partition the problem geographically before solving. This paper documents an alternative: treating the full fleet as a single workload and distributing computation internally through constraint-aware clustering, boundary rebalancing, and route-level optimization.

paper: https://optimization-online.org/?p=34599

Hi, I am almost done with my MVP. I have a working demo and a full paper documenting the architecture, but I'm stuck on where to actually put it out there.

arXiv requires an endorsement I don't have. I ended up submitting to optimization-online org but I honestly don't know if that's the right move or just noise. No academic affiliation, no network in this space.

For people who've gone through this: how did you get your technical work in front of the right people before you had any credibility built up?
Did publishing even matter, or did the demo do all the work?
Thanks!!

The core idea: treat the full fleet planning problem as a single coherent problem instead of pre-splitting into zones. Built around three parallel stages: constraint-aware clustering, distributed boundary rebalancing, and fast route-level optimization. With a multi-level graph caching layer that's the main driver of the scaling behavior.

Benchmarked on Amazon's public routing dataset: 23.3% less distance, 11.1% fewer routes.

Full paper: https://optimization-online.org/2026/04/rethinking-last-mile-routing-at-scale-near-linear-planning-on-commodity-hardware/

Happy to answer questions on the architecture.

*Disclosure: I built this system.*

Built a last-mile routing architecture that processes 1M stops in ~20 min on a MacBook Pro M4, no distributed system or specialized infrastructure needed.

Benchmarked against Amazon's public routing dataset: 23.3% less total distance, 11.1% fewer routes.

Paper: https://optimization-online.org/2026/04/rethinking-last-mile-routing-at-scale-near-linear-planning-on-commodity-hardware/

Disclosure: I built this system.

Hi everyone,

I’m an independent researcher working on large-scale last-mile routing systems, and I’m preparing to submit a paper to arXiv. Since this is my first submission in this category, I need an endorsement to proceed.

The work focuses on a routing architecture that:

• handles up to ~1M stops
• runs on commodity hardware
• shows near-linear empirical scaling
• outperforms the Amazon Last Mile dataset baseline

Here’s a technical writeup for context:
https://medium.com/@martinvizzolini/a-last-mile-optimizer-that-outperforms-amazons-routes-on-a-laptop-24242f93eb74

If anyone here has endorsement privileges in cs.DS / cs.AI / related areas and would be open to reviewing the paper or helping with endorsement, I’d really appreciate it.

Happy to share the full draft or details privately.

Thanks!