Commercial distributor
Turning spreadsheet-driven inventory decisions into a working application
A commercial distributor made purchasing and allocation calls across projects, vendors, and warehouses with spreadsheets and individual judgment. I built a working prototype that applies those rules consistently, so leadership can test the approach before investing in a full system.
Functional prototype. Not in production, and savings have not been measured.
The situation
A commercial distributor buys inventory for projects that run on shifting schedules, across several vendors and warehouses. When a project slips, material can arrive months before it is needed. It takes up warehouse space, ties up cash, and gets handled more than it should.
Holding an order back is not a simple fix either. Delay the wrong purchase order and a different project runs short. The people making these calls were doing it with spreadsheets and their own judgment, one order at a time.
The real constraint
The information existed. Project dates, open purchase orders, and stock on hand were all known somewhere. What was missing was one place that connected them, so a change to one project showed its effect on every other project drawing from the same inventory.
That made it a rules problem more than a data problem. The business already had rules for when an order can wait and when stock can move between projects. They lived in people's heads and got applied a little differently each time.
What I built
I built a functional prototype that models projects, products, warehouses, purchase orders, and delivery schedules together. When a project's dates change, it recalculates demand and shows the consequences across every project, not just the one that moved.
It flags purchase orders arriving well before they are needed, checks whether an order can safely be held, finds stock that could move to another project, and warns about shortages before they affect a commitment. Safeguards block any hold or reallocation that would leave another project short. Leaders get a summary of inventory age, warehouse distribution, and open exceptions, and vendor hold windows and planning assumptions are settings rather than code.
Where it stands
This is a working prototype, not a production system. It shows that the decision rules can be captured and applied consistently, and what the operating model would look like day to day.
The goal is less excess inventory, released working capital, and better use of warehouse space. Those savings have not been measured, and this case study does not claim them.
Why build the prototype first
The problem was clearly worth solving, but the right solution was not obvious, and the rules were too important to guess at. A prototype put those rules in front of the people who apply them and exposed the gaps before anyone paid for a full system.
It also gives leadership something concrete to decide on. Proceed, revise, or stop, with a working model in front of them instead of a proposal.
Technology
A custom web application with a calculation engine that evaluates supply and demand across all projects at once, built with Next.js, TypeScript, and PostgreSQL.