Warehouses can't keep up with order volume accurately and the company is not able to scale locations due to major design deficiencies in the bespoke inventory management system.
Warehouse teams are able to efficiently fulfill orders accurately and the company is able to confidently expand to new locations utilizing a rearchitected inventory management system.
FastAF is a quickly growing startup leading the field in near-real time delivery of goods. Think of them like Amazon but deliveries in less than 2 hours.
Over the course of six months I lead the development and oversaw the deployment of a replacement inventory management system tailored to solving the scaling challenges of quick-commerce.
Conversations began with Mike and Nate, warehouse managers, and the executive team. The challenges presented seemed limitless but centered around accuracy and efficiency. The executive team was not able to accurately get an understanding of inventory levels or velocity and the warehouse teams were unable to use the software to track inventory locations within the warehouse. Both sides were duplicating work via spreadsheets and inventory management policies were not able to be applied uniformly across warehouses.
After building a detailed understanding of the problems faced by the teams I set to work identifying the current state of the bespoke inventory management system that powered FastAF. I was told that the original version had been built within a couple weeks and it showed.
I identified that the principal source for all of the issues was the inability for the software to actually track the specific location of inventory within a warehouse. This made it impossible for the warehouse teams to track important metrics like shelf-life or expiration dates or even to reliabily track quantities. The system made it impossible to fulfill orders while managing inventory and the company did not have the resources to hire additional warehouse workers to expand operating hours.
Unfortunately all of the fulfillment, reporting, merchandising, and management software was written specifically for this inadequate system. Any solution was going to require not just a revamping of the inventory management system but also all of the software it interfaced with.
After studying the existing codebase and researching alternatives I developed two potential solutions and presented them to the executive team. The first solution was to replace the bespoke system with an off-the-shelf system. The second solution was to whole-sale replace the foundation of the existing system.
Replacing the bespoke system with an off-the-shelf system was a good solution in terms of offloading development time in the long-term but it presented a lot of challenges. Because all of the interfacing software would need to be massively changed to integrate with the new system it was by far the most time-consuming and expensive solution in the short-term. It also would create new challenges because existing software did not fully match the real-time fulfillment goals of the company. I developed a cost estimate of 7,000 engineering-hours effort for reaching deployment of this solution plus expensive licensing fees.
The solution the executive and warehouse teams settled on was to replace the foundation of the existing system with a rearchitected one. I estimated this solution to be 1,500 engineering-hours effort up-front. The initial version would not have near as many features as the off-the-shelf software but we could tailor the initial features to the company's immediate needs as well as add new features later when the budget was available. The reduced cost and increased flexibility of this solution appealed to everyone involved.
I personally developed the intial prototypes of the replacement system over the course of a month. My focus was on understanding how to best model the underlying relationships between inventory and locations within a warehouse. I worked closely with the Mike and Nate to verify the prototypes I was building in Ruby on Rails to ensure that the architecture would allow them to efficiently and accurately track and manage inventory. The key was developing a "Plate" model in Ruby on Rails that would encapsulate all of the information about a group of inventory such as quantity, expiration date, and lot number and then storing the historical changes to this model. Once this model was established it could be related to locations and products/variants.
This new Plate model I developed would then allow the warehouse team to efficiently manage inventory in logical groups instead of having all of the batches of inventory mixed together within the software which required them to essentially manage inventory at the unit level and it made it impossible to accurately track inventory as it moved throughout the warehouse and on to customers. The new model and relationships I established would also allow the inventory planning teams and executive teams to have much more accurate and detailed insights into the existing inventory state and velocity. Every one was super excited with demos of the initial prototypes.
After building the prototypes I expanded development efforts to the rest of the internal operations team. I lead the team in building out the new system by developing a detailed description of the software we needed to build and managing the development timeline. I handed off direct development efforts to the team and worked closely with them to ensure key targets were met accurately, on-time, and within budget.
While the rest of the team focused on building out the new system I tackled the next hurdle which was deployment. We had to develop a way to deploy the new system with zero down-time and we had to be sure was accurate. I decided the best solution would be to run both systems in parallel. This would allow us to validate the new system and allow us to seamlessly cut-over to it when we were sure it was ready.
I started by detailing the APIs we would need on the client-side to support the new system and how these new APIs would relate to the existing system. I then worked with the rest of the engineering team to fully implement the new APIs. It was very complex but I focused on making sure the team always had working versions to test and with persistent effort we completed the initial version of the new system and its integration with all of the clients.
I oversaw the effort to migrate all of the data into the new system and deployment of the new APIs. This was carried out without downtime.
After initial deployment we further developed new client-side tools to give us detailed insight into the performance of the new system. These new tools allowed us to cross reference the data in the new system with the data in the old system as well as data in the separate sales system. While the company continued to rely on and use the old system we were able to monitor and analyze performance of the new system. We found a few bugs that lead to inaccuracies in the new system. After fixing the initial issues I was able to verify that not only was the new system performing well but it actually demonstrated some previously unknown quality issues with the old system.
Now that I had proven the new system was functioning correctly I developed a detailed deployment plan for switching over everything to the new system. I developed a mechanism that would not only allow us to switch over to the new system but also to seamlessly reverse the switch if we discovered any new problems. I also ensured we had tested backup systems in place.
Late one night, after the last orders were fulfilled for the day, we switched over to the new system. We worked closely with all of the warehouses to then carry out extensive validation on their end to ensure it all went smoothly; and it did! At the same time we kept the old system running in parallel and over the next few weeks were focused on validating the new system.
After six months from start to finish, we did it! I was able to verify that the new system was function correctly and we had pulled off the migration without any downtime. Mike and Nate and the rest of the warehouse teams were super excited because they could now accurately and efficiently manage their inventory in a way they had never been able to before. They were able to retire nearly all of their extra spreadsheets. The engineering team was excited because they now had a much better foundation to build upon and the executive and supply management teams was also thrilled because they could now gain much deeper insights into the inventory and manage it from a high-level in a way that they had never been able to before. The executive team could now focus on expanding the fulfillment locations without having to worry about figuring out how to scale the software to meet their business goals.