Cargo Tetris: Fleet Optimizer

As a load planner, I need to build truck manifests that respect weight and space limits at the same time, without spending an hour on a spreadsheet the next planner would build differently, or doing the arithmetic by hand, or skipping it.

Load planning for a 500-person organization was entirely manual. Junior planners built manifests in spreadsheets or by hand, from knowledge passed down informally. The working heuristic was to order more trucks than you think you need, since coming up short costs lead time, then load the heavy items first and fill in around them. It was vague, applied inconsistently, and produced trucks that routinely ran under capacity on both weight and floor space.

The downstream cost wasn't visible on any dashboard. Extra sorties meant more fuel, more driver-hours, more vehicle wear, and longer resupply cycles. Tactically, it meant larger convoy footprints and a higher chance of detection by hostile forces. No one measured utilization, so no one knew how much capacity was being left on the table, or that the problem was systematic rather than situational.

I ran a cross-functional working group with drivers, planners, and logistics NCOs, not to propose a solution, but to map exactly how load decisions were being made. Three findings shaped the build:

• Weight and space were treated as independent constraints. A truck could be "full" by floor space while still well under weight capacity, or vice versa. Planners had no way of spotting the slack, let alone using it.
• Load plans were built by familiarity, not optimization. Specific cargo types always went on specific trucks, a legacy of who trained whom rather than what the math said. Variance between planners was high.
• Single-objective optimization, every time. Planners optimized for whichever constraint was most painful in the moment, whether speed, fuel, or convoy size, without a tool that could solve all three together. The result was a different load plan every cycle, depending on who was on shift.

The planners knew their cargo. What they lacked was a tool that enforced both limits at once and produced a plan the next planner could check.

Like the forecasting tool before it, this one had to ship as a downloadable, offline-capable artifact: operators in the field don't get internet, and a web app at the point of use was a non-starter.

I designed a single-file HTML/JS MVP using the First Fit Decreasing (FFD) greedy heuristic, a bin-packing algorithm that provably produces solutions within 11/9 of the mathematical optimum while running in polynomial time:

• Cargo items sorted by weight, heaviest first, so the hardest-to-place items get priority before trucks fill up
• Each item placed in the first existing truck where both weight AND floor space constraints are satisfied simultaneously
• If no existing truck can accept the item, a new truck is opened
• Output: minimum truck count, per-truck manifest grouped by SKU with counts, weight and space utilization percentages, warning flags for trucks approaching limits

I iterated the manifest output format twice based on planner feedback. The first version listed individual item placements; planners found it unreadable in the field. The second version grouped items by type with quantities. That became the working format and was adopted without modification.

The dual-constraint check was the critical design decision. Single-constraint tools (weight-only) consistently missed the case where a truck cubed out before hitting its weight limit. Modeling both simultaneously is what drove the utilization improvement.

The first build packed trucks correctly and almost nobody used it twice. The algorithm was never the problem. The data entry was. A planner had to enter dimensions and weight for every item, and because real manifests repeat the same handful of cargo types dozens of times, they were entering the same numbers over and over before they could get an answer.

That put the tool behind the spreadsheet it was meant to replace. The spreadsheet was worse at packing but faster to fill in, and a planner under time pressure will take the tool that gets them to an answer sooner every time.

The fix was presets: the recurring cargo types stored with their dimensions and weight, so building a manifest became selecting a type and a count rather than re-entering measurements. It cut the time to a load plan sharply, and it removed a whole class of transcription error along with it. Adoption followed almost immediately, which is the clearest signal I had that the packing quality was never what had been holding it back.

As a load planner building a manifest on a ramp before a night movement, I need to read the plan off a screen without becoming the brightest thing in the motor pool.

Load plans get built at the worst possible time: pre-dawn, outdoors, in the hour before a movement when everyone is already behind. The forecasting tool had already run into what that means for an interface, so this one adopted the same standard rather than rediscovering it.

• Black canvas with a red foreground, so reading a manifest does not cost the planner their dark adaptation or put a pale rectangle in open terrain.
• The same operator brightness control, persisted between sessions. Consistency mattered here, because the same people use both tools on the same night.
• Utilization state carried by luminance and text, not hue. A truck approaching its weight limit is flagged with an explicit label rather than an amber fill, which also removed a real failure mode: the original light build used amber and red warnings that were nearly indistinguishable on a sun-washed screen.

Like the forecasting tool, it ships as one self-contained HTML file with no dependencies, no build step, and no network calls, because a load plan is needed exactly where connectivity is not.

• Median convoy size down 25%, measured across manifests (from 4 systems to 3), with fewer trucks required to move the same cargo volume, freeing vehicles and drivers for other missions
• Roughly a third more cargo per truck, implied. Moving the same loads on three systems instead of four is the observable fact. Utilization was never tracked before the tool, so the per-truck gain follows from the convoy figure rather than from a separate measurement
• Adopted as the unit planning standard. Planners stopped building spreadsheet manifests and ran the tool for every major load operation, so every manifest was built the same way and could be checked after the fact