A stock transfer planner on AWS for a few dollars a month
Branch three has forty of something that has not sold in two months. Branch one sold out of it last week. The obvious answer is to move some, and for a fourteen-pound item with a four-pound margin, a van trip and two people’s time makes that a way of converting stock into a smaller amount of stock somewhere else. This post walks through a small system that does the arithmetic first.

Key takeaways
- Test the economics before proposing a transfer. Most fail.
- Real demand at the destination, not merely a low stock level.
- Never leave the source below its own reorder point.
- Wait for a vehicle that is going there anyway; it changes the arithmetic entirely.
- Designed on AWS for about $2 a month.
The whole system on one page
Before any code, here is the shape of what we are designing.
The cost of moving a box
Picking it at one end, packing it, paperwork, the vehicle, receiving and putting it away at the other end. For a dedicated trip that is tens of pounds before anybody counts the vehicle; on a movement that was happening anyway it is the picking and receiving, which is still several pounds of somebody’s time.
Against that sits the benefit, which is not the value of the stock. It is the margin on the sales that would otherwise be lost, discounted by the probability those sales actually happen and by whether the item would have sold at the source eventually anyway.
What runs (the inside)
- Imbalance detection. Finds stock that is in the wrong place relative to where it sells. Part 2.
- The economic test. Decides whether moving it is worth more than leaving it, and protects the source. Parts 2 and 3.
- Batching. Holds proposed transfers until a vehicle is going that way. Part 4.
One transfer, end to end
- Compute
- Security & identity
- Analytics
In plain words
Branch three has forty units of an item and sells about one a month, so it is holding more than three years of cover. Branch one sells nine a month and has two left, which is about a week.
Moving twenty-two units protects roughly two and a half months of sales at branch one. At a margin of a few pounds each and a realistic probability that most of those sales would otherwise be lost, the benefit is around twenty-eight pounds. Picking and receiving on an existing movement costs about nine, so it clears.
The source keeps six units, which is six months of its own demand, so branch three is not left unable to sell the item to the occasional customer who wants it. And it goes on Thursday’s van, which is already making that trip, rather than on a dedicated journey that would have made the whole thing uneconomic.
Design rules that shaped every decision
- Compare the margin protected against the full cost of moving, both ends.
- Demand at the destination means sales history, not a low stock number.
- Never take the source below its own cover requirement.
- Batch onto existing movements; a dedicated trip needs a much larger benefit.
- Track in-transit explicitly. Stock in a van is at neither end.
- Detect and block ping-pong: the same item moving back within a quarter.
Why this shape
Multi-site stock imbalance is genuinely expensive and the standard response makes it worse: a report of imbalances, generated weekly, which somebody works through by moving things. That produces a great deal of van time and picking labour, a fair number of transfers that reverse themselves, and stock that is temporarily missing.
The version that works rejects most of the list. What is left is a small number of transfers that clearly pay, that do not hurt the source, and that ride on movements already scheduled. The value is as much in what it declines to propose as in what it proposes.
The next four posts walk through each piece: when a transfer is actually worth it, how the source gets protected, how transfers get batched onto movements that already happen, and what in-transit stock does to your numbers. One diagram per post, a cost breakdown, and an engineering reference at the end.
All posts