Most warehouses solve uncertainty by buying space.
If you do not know what stock will arrive, what will sell, and what will still be sitting there in six months, the safest answer is to keep the building half empty. There is always another bin. There is always room to recover from a bad placement decision.
The alternative is to run the warehouse fuller and pay for it in labour. Stock goes wherever there is room today, then gets moved when tomorrow’s delivery arrives. Bins become awkward. Packaging gets crushed. Staff rely on memory, exceptions, and “ask the person who knows”.
This system was built to create a third option: run the warehouse much more fully without making it harder to work.
The question it answered was simple.
Where should this product go?
The answer was not based only on space available today. It used purchase orders, current stock, expected sales, returns, product volume and bin volume to understand how stock was likely to change over the next year.
A bin has a future. So does a product.
The useful idea was to stop treating a bin as empty or full.
Each SKU had a twelve-month space profile: how much room it was expected to need as deliveries arrived and sales reduced stock. That profile was compressed into one 36-digit value. Every bin had a matching value showing its available space over the same period.
Once those values existed, the live decision became very fast. The database did not need to run a warehouse simulation every time someone scanned an item. It could exclude unsuitable bins, sort the remaining ones and return the closest fit.
That was the trick. Because the twelve-month view was packed into one fixed-width number, normal sorting did the work. The system did not need to reason through each month during the scan. A bigger number was just bigger, and the best fit naturally rose to the top.
This mattered because the system ran in a real warehouse: handheld scanners, wireless network, low-powered servers, people moving quickly. A slow answer would have killed trust. Instead, scans returned the correct bin effectively instantly.
Fullness became a setting, not a daily problem
The system also managed target occupancy automatically.
A bin may physically hold 100% of its volume, but that does not mean it should be run at 100%. Real stock is awkward. Boxes crush. Suppliers overship. Forecasts are useful but imperfect. Staff need room to pick and put away without fighting the bin.
Because the system knew future purchase orders, product volumes and total warehouse capacity, it could recalculate the target occupancy level each month. If the next twelve months showed plenty of space, bins could be kept looser and easier to work. If incoming stock meant pressure was building, the system could safely increase occupancy and use the warehouse more aggressively.
That turned fullness from a daily problem into a managed setting.
The result nobody designed
The most interesting result was something the system discovered on its own. Because the business sold seasonal stock, summer and winter products naturally started to pair together. As winter stock arrived and grew in volume, summer stock was selling down and making space. Later, as winter stock sold through, summer stock began arriving again and filled the same bins back up.
No one had to hard-code “put summer with winter”. The system found SKUs that could cohabit because their stock movement had opposite shapes.
That is what made it more than a space checker. It was not asking, “Where is there room today?” It was asking, “Where will this product live well?”
What it changed
- Put-away became nearly 300% faster.
- Effective storage capacity increased by over 250%.
- Stock damage reduced, and stock-location problems pretty much disappeared.
- Stop-moves caused by lack of room in the bin disappeared completely.
- The warehouse team reduced from five people to around one and a half.
- Development paid for itself several times over within the first twelve months.
Those results did not come from expensive hardware or a complicated interface. They came from making thousands of small decisions better, faster and more consistently.
The instruction to staff stayed simple.
Put this product in that bin.
Behind that instruction, the system had considered product size, stock on hand, future deliveries, expected sales, available warehouse capacity and how full the business could safely run the building. It had done that quickly enough that the person doing the work did not have to think about any of it.
Why I still like it
Looking back, what I like about the system is not that it was polished or elegant in code terms. It was built for a specific business, with real constraints, on old infrastructure.
What I like is the shape of the thinking.
It took a physical problem and found a compact representation for it. It used forecasting only where forecasting helped an immediate operational decision. It respected real warehouse pressure: staff time, walking distance, bin capacity, awkward stock, fragile packaging, wireless scanners and limited servers.
It used the database for what databases are good at: filtering and sorting large sets quickly. And it made the answer fast enough to be used in the flow of work, not as a report someone looked at later.
That is often where good software has the most value. Not in making something look technically impressive, but in finding the right simplification.
In this case, the simplification was to treat warehouse space as a future shape, then pack that shape into a number the database could sort. Every SKU had a future space profile. Every bin had a future available-space profile. Bin selection became a matching problem.
The result was a system that could answer, almost instantly, “Where should this go?” while quietly considering things a person could not reasonably calculate in their head: what is arriving, what is selling, what space should be protected, which products fit together over time, and how to keep the warehouse easy to work in rather than merely technically full.
That kind of work sits between software, operations and commercial judgement. It is not just writing code to match a specification. It is understanding how a business moves, where friction appears, and how to turn that into a decision engine people can trust.
The instruction at the end was humble: put this product in that bin. But behind it was a model of the warehouse, the stock, the forecast, and the cost of getting the decision wrong.