Logistics & Routing Optimizer
A routing-and-distribution optimization engine — solves vehicle routing problem (VRP) variants for the business's fleet and constraints, produces daily route assignments with documented cost reduction vs. the prior method.
- Engagement
- 8–14 week build · ongoing operation
- Built for
- Logistics directors · Operations managers · Distribution leads
Last-mile and distribution routing decisions are made in spreadsheets or by dispatcher intuition — both of which produce routes that look reasonable but are demonstrably non-optimal against fuel, time, and vehicle-capacity constraints.
What this is
A classical-OR routing engagement for logistics operations where routing decisions move real cost. Three layers:
- Problem formulation. The business's routing problem expressed as a VRP variant with the specific constraints encoded — time windows, vehicle capacity, driver skill, pickup-and-delivery sequencing, multi-depot logic.
- Solver. Gurobi or OR-Tools, depending on license and scale. Hybrid heuristic-plus-exact methods for the larger problem instances.
- Operational integration. Daily route generation, dispatcher UI for review and override, integration into the fleet's telematics or routing system for execution.
How it's built
OR-Tools as the default solver, Gurobi where the business already licenses or where the problem scale justifies. Python orchestration layer for the daily problem formulation and result post-processing. Dispatcher UI in a lightweight web app.
What you get
- The formulated VRP variant with documented constraint handling.
- The solver deployment.
- Daily route generation pipeline.
- Dispatcher UI for review and override.
- Baseline-and-improvement measurement documentation.
Engagement is shape, not list.
Length and price are functions of the data and the destination. The shape below is the typical engagement.
- Length
- 8–14 week build · ongoing operation
- Lead
- Bogdan
- Cadence
- Async, weekly
- Bar
- Production
Scoped during the discovery call against the actual data and the operation it integrates with.
Principal engineer. Architecture and most code ships through one keyboard.
Written updates between, calls when the decision needs the room.
Async correctness, capacity under burst, observability at every boundary.
Products this composes with.
Same suite, or vertical-specialized versions in another.
- Same suite · Operations Algorithms Suite
Workforce Scheduling Engine
A workforce-scheduling optimizer that produces shift assignments against the business's constraints (skills, availability, labor law, demand forecasts) — runs weekly or daily depending on the cadence, with manager-side UI for review and override.
- Same suite · Operations Algorithms Suite
Production & Resource Planner
A linear-programming model for the business's production-planning problem — what to make, how much, in what mix, allocated to which demand. Run weekly or per planning cycle, with documented improvement vs. the prior method.
What buyers ask about this one.
Why classical OR instead of ML?
Routing has well-understood mathematical structure (vehicle routing problem, traveling salesman, related variants). Classical OR solvers (Gurobi, OR-Tools) produce optimal-or-near-optimal solutions deterministically, with explainable constraint handling. ML approaches to routing exist but underperform classical methods on well-defined problems with hard constraints. We use ML where ML is the right tool; for routing, OR is the right tool.
Which VRP variants do you handle?
Standard CVRP (capacitated), VRPTW (with time windows), MDVRP (multi-depot), VRPPD (pickup-and-delivery). Where the business has constraint variants we haven't pre-built (e.g., driver-skill matching, multi-trip-per-vehicle, fleet heterogeneity), we extend the formulation.
What's the typical cost reduction?
Vs. dispatcher-intuition routing: typically 8–18% reduction in vehicle-miles, with similar effects on fuel and time. Vs. spreadsheet routing with reasonable manual heuristics: typically 4–10%. The engagement scopes a baseline measurement so the reduction is measurable, not asserted.
How does it handle dynamic changes during the day?
Re-optimization runs as needed — for fleets with mid-day stop additions or route disruption, the engine re-solves against the updated constraint set. Latency is sub-minute for typical fleet sizes; for very large fleets the engagement scopes the architectural changes required.
Pricing?
Scoped to fleet size, constraint complexity, and integration depth. Discovery call covers all three.
If the deliverable matches the gap, the next step is one call.
We'll scope length and price against your data and the operation it integrates with. No retainer, no fishing.
Bogdan and team · async-first · OP—2026