Inspiration
We built Opti-Damm after digging into how beverage logistics actually works beyond the spreadsheet level. A delivery truck is not just “cargo + route.” It is a moving warehouse with time windows, unloading constraints, returnable containers, stack rules, side access limitations, and drivers trying not to spend half the stop searching for the right pallet.
The challenge that stood out to us was the interaction between routing and loading. Most systems optimize one or the other. In reality, they are tightly coupled. A slightly shorter route can become slower overall if the truck is loaded badly. We wanted to build something that treats the truck as a physical operational system, not just a capacity number.
What it does
Opti-Damm is a delivery execution simulator for beverage logistics. The platform takes real delivery datasets and turns them into route-aware truck loading plans with interactive diagnostics and 3D visualization.
The system simulates how pallets and cargo units are placed inside the truck while accounting for physical constraints such as slot layouts, stackability, unloading order, accessibility, and delivery windows. Instead of treating the truck as a simple capacity number, Opti-Damm models it as a changing operational space that evolves throughout the route.
What it does:
- Loads clients in the historic stop order by default, or in historic-load it keeps the same loader but re-optimizes the delivery route with nearest-neighbor, 2-opt, and or-opt in /simulator/algorithms/historic_load.py.
- Splits each client’s lines into chunks so tall or heavy items don’t get packed as one huge block.
- Groups chunks into footprint buckets by pallet class and snapped dimensions, so near-identical items share a packing lane.
- Within each bucket, it sorts late-delivery clients first, then heavier SKU chunks first, so delivery order becomes a physical LIFO stack.
- Tries to place chunks on existing columns first, but only if they match footprint, class, weight limit, and delivery-order safety.
- Opens new columns on existing pallets next, then fresh pallets, then overflow if nothing fits.
- After the main pass, it tries recovery passes: rotate the footprint 90 degrees, stack same-client overflow on same-client items, then force-pack as a last resort.
- Assigns pallet slots with a final balancing step: KEG pallets go toward the back, BOX pallets toward the front, and then it hill-climbs swaps to reduce lateral and longitudinal center-of-mass error.
The key safety heuristics are:
- No heavier item on top of a lighter support.
- No item that would be delivered earlier than the thing supporting it.
- Height, pallet footprint, and pallet weight caps are enforced throughout.
- Same-client stacking is preferred because it reduces unload friction.
- Cross-client mixing is avoided unless the truck would otherwise overflow.
Returnables are handled separately in /simulator/algorithms/restock_strategy.py and opti-damm-clone/simulator/algorithms/ virtual_truck.py: empties are placed floor-first, then on other empties, and the historic strategy refuses to park empties on cargo.
How we built it
We built Opti-Damm as a full-stack simulation pipeline.
The backend processes delivery and route datasets, generates loading configurations, validates spatial constraints, and computes diagnostics related to accessibility and unloading order. The loading engine models the truck as a slot-based structure with configurable geometry and placement logic rather than a flat storage container.
The frontend renders the simulation directly in the browser through interactive 2D and 3D views. We built custom truck visualizations, pallet rendering, route timelines, diagnostics panels, and load inspection tools to make the optimization logic understandable instead of opaque.
For the 3D system, we used a canvas-based renderer and iterated heavily on geometry, spacing, and rendering behavior so the cargo remains visually readable and accurately reflects the underlying load state. We also built export and transformation layers that convert simulation output into visualization-ready payloads consumed by the frontend renderer.
Challenges we ran into
The biggest challenge was balancing realism with usability.
Real logistics becomes complicated very quickly. Even simplified routes involve interacting constraints: delivery windows, weight distribution, pallet access, returnable cargo, stack rules, and unloading order. It was easy to make the model either unrealistic or impossible to interpret.
Another major challenge was visualization accuracy. We wanted the UI to function as an operational tool rather than a static presentation. That meant iterating on slot layouts, obstruction logic, pallet grouping, and color mapping so users could immediately understand why the system produced a given loading plan.
Accomplishments that we're proud of
We are especially proud of building a system that keeps the operational logic visible instead of hiding it behind optimization scores.
Rather than generating a black-box answer, Opti-Damm makes the loading process inspectable. Users can see how pallets are arranged, which deliveries are blocked, how unloading order affects efficiency, and where friction points appear during the route.
We are also proud of turning a fairly abstract logistics problem into something tangible and interactive within a hackathon timeframe.
What we learned
One of the biggest lessons was that logistics optimization is deeply physical. A truck is not just a container with a capacity limit — it is a constrained spatial system that changes state throughout the day.
We also learned how tightly coupled operational decisions are. Route optimization, loading strategy, unloading ergonomics, and reverse logistics all affect one another. Treating them separately produces solutions that look good mathematically but fail operationally.
On the technical side, we learned a lot about simulation pipelines, spatial modeling, and how much clarity matters when visualizing complex systems.
What's next for Opti-Damm
The next step is making the simulator more adaptive and operationally aware.
We would like to expand the optimization engine with dynamic route adjustments, traffic-aware timing, predictive unloading duration, and better handling of reverse logistics. We also want to improve the warehouse side of the system by exploring loading recommendations that optimize not only delivery efficiency, but also preparation complexity and driver ergonomics.
Built With
- docker
- fastapi
- javascript
- leaflet.js
- next.js
- numpy
- postgresql
- python
- railway
- react
- sqlalchemy
- three.js
- uvicorn
- vercel
Log in or sign up for Devpost to join the conversation.