We're nextmv (https://nextmv.io/). We launched our decision automation platform on HN 8 months ago (https://news.ycombinator.com/item?id=22630426). At the time, our tools were backend optimization and simulation libraries for building custom decision models.

As our users scaled, we learned a bit about making this easier to deploy and manage. At first we focused a lot on integration and deployment. That hasn’t changed. With a 1-line code change, a model goes from CLI testing on a local machine to AWS Lambda. Now you can now trigger decision Lambdas from S3 PUTs, run golden file tests in CI, and profile decision models for memory consumption.

We have users live in prod with nextmv decision models in Lambda, Step Functions, K8s and Azure. But deployment is only half of the equation. Making models easier to build is hard. To do this, we leaned into composability.

Take delivery and distribution. Every delivery operation is unique. Some have central depots and employ drivers. Others have user-driven pickup points and gig drivers. Functionally though, we compose these models from the same pieces.

So we layered reusable components onto our optimizer:

Models (vehicle routing, packing, clustering)

Constraints (capacity, time windows)

Measures (Haversine, OSRM)

Model components let us quickly describe vehicle routing mechanics. Constraints make sure we follow operational rules like not over-packing trucks. Measures let us flexibly compare the costs of solutions. Just like the optimizer, every component is an interface so you can swap in your own implementations.

We dogfooded and built Nextmv Cloud (https://cloud.nextmv.io/), our API for nextmv-developed models. Alpha is live with a model we know well: fleet routing. We’re looking for feedback as we mature the model, and Nextmv Cloud as a whole. Check it out and drop us a line at [email protected]!

Stay tuned for a Show HN post! (spoiler: gophers + lambdas all the way down).