We're Carolyn and Ryan, founders of nextmv (https://nextmv.io/). We help developers build and test logistics algorithms faster. These are things like routing delivery vehicles, assigning nurses to patients, and managing supply chains.
We used to work in systems engineering and operations research on big government projects, including missile simulations and airport runway management. A few years ago, we pivoted to working on food delivery at Zoomer (YC S14) and later Grubhub. It turned out that making on-demand pizza and taco delivery efficient and reliable required the same optimization and simulation techniques, but in real time.
Real-time routing and assignment problems have a number of interesting characteristics that make them challenging. For example, they follow business rules such as pickups preceding deliveries, time windows for deliveries which may or may not be violated, and driver capacities. Their inputs are constantly changing. They can get very large (1000s of orders, 100s of drivers). And they require high-quality solutions in seconds.
People usually think of NP-hard problems like the Traveling Salesman when routing and dispatch optimization is mentioned, and we do have to solve those. But the biggest challenges turn out to be ones that are more familiar to the software engineering community. There is no easy equivalent to the software unit test for techniques such as Integer Programming and Constraint Programming. And integration into modern software stacks is nontrivial. In the end, we had to build new tools so we could work faster.
Traditional dispatch and scheduling algorithms take months to develop, integrate, and test. That is a problem when businesses change rapidly. This is happening in delivery, which has exploded over the last few years and is likely to only get bigger. Existing tools require domain experts to translate business rules into models. This makes organizations unable to keep pace with change.
During our research into appropriate techniques, we learned about Decision Diagrams (http://www.andrew.cmu.edu/user/vanhoeve/mdd/). DDs represent optimization problems as the search for a shortest (or longest) path over a layered, directed, graph. They are state-based, have few restrictions on problem representation, and can outperform other techniques (depending, of course, on the model). We find them particularly attractive for getting started with simple models and integrating them into software stacks. Since there weren't any industrial-grade DD solvers, we built one. And we started nextmv to give companies the modeling, optimization, and simulation tools we wish we'd had.
Our tools are for software developers with deadlines. They let you flexibly model nearly any business rules, easily integrate models into software stacks, and test them so you know they're behaving as you expect.
What can you do with them? Dynamically route buses based on passenger requests. Minimize shipping cost for packages. Schedule workers based on demand forecasts. Hop (our optimizer) lets you model decision problems as state machines. Dash (our simulator) is also state-based, so you can optimize and simulate using the same code.
We've prioritized making things developer-friendly. You can write and test models like any other software. Larger, more complex models can be composed out of smaller, simpler ones. Optimization and simulation models are built from Go source into simple binary artifacts. (We think of this as Docker for decision science.) They come with pre-built runners that make going from development to testing in CI to production deployment trivial. They have JSON I/O for easy integration, and run in a CLI, over HTTP, or in Lambda.
Not all operational decisions need complex optimization, but they all benefit from simple automation and integration, fast iteration cycles, and continual visibility. We give you this from the beginning, then let you layer in fancier optimization stuff if you need it later. Here's a screen cast showing a simple routing model in Lambda: https://www.loom.com/share/65ad523138364bf7bac48524efb620e0. We've seen developers without optimization backgrounds create models to minimize delivery time and deploy them to Lambda in less than 24 hours.
We're eager to hear about your experiences in this area and/or ideas on faster ways to get automation into production. We would love any and all feedback that this community can offer, so don't hold back!
by Andrey
Azimov