The Question Isn't “Buy OR Build?” — It's “How Do We Build and THEN Buy”?

A Case Study in Inventory Optimization and Client Communication

I had a recent consulting engagement to help a Fortune 500 company understand tradeoffs between different network designs, reorder points, and quantities. But within the first week, I realized we had a communication problem that would shape the entire four-month engagement.

Four stakeholder groups sat around the table, each asking for something different. Executives wanted high-level strategy for network redesign. Operational teams needed tactical answers for day-to-day procurement decisions. Data scientists wanted a custom coding solution they could own and extend. IT teams were in the middle of implementing a new supply chain software platform and needed to know how our work would integrate.

The surface-level request was simple: "Give us specific answers." But the unvoiced need was something else entirely: a decision-support tool that didn't exist yet, that they didn't know how to articulate, and that would need to serve all four audiences simultaneously.

The Lesson: Building the Bridge to Buying

Here's what I learned: when a client is caught between building custom solutions and buying enterprise software, they don't need you to pick a side. They need you to build the bridge that makes the buying decision possible.

The IT team wasn't ready to configure their new platform because they didn't know what questions it needed to answer. The executives couldn't evaluate network design options without understanding the end-to-end system. The operational teams couldn't trust any system without seeing it work on their actual data. 

Our role wasn't to replace the enterprise system. It was to build the proof-of-concept that would show everyone what inventory optimization could deliver, create the shared vocabulary for cross-functional decision-making, and generate the requirements that would guide the platform implementation.

In practice, this meant:

Delivering immediate value while building for handoff. We answered the pressing question about hub-and-spoke network design for their Texas frozen food distribution (a real decision with real dollars attached). But we built it as a reusable framework, not a one-off analysis. When we handed off the code, we included a detailed roadmap: how to scale, which levers to pull, how to add features like results-based item segmentation or optimization of fill rates given warehouse space constraints.

Creating alignment before creating code. We facilitated a working group to define use cases, prioritize them, and walk through one concrete example together. This collaborative scoping process forced teams to get exact about their priorities and their needs. The executives saw their strategic questions answered. The operational teams saw their real-world constraints reflected. The data scientists saw modular code they could extend. The IT team saw a requirements document for platform configuration.

Showing, not telling. We ran the simulations across a huge variety of possible parameters and showed the Pareto frontier of cost vs. space tradeoffs. Suddenly the conversation shifted from "how do we optimize inventory?" to "which of these tradeoffs reflects our actual priorities?" The tool didn't make the decision. It made the decision visible.

By the end of the project, the Chief Supply Chain Officer told us our tool would become the springboard for a new network design team reporting directly to him. 

The Technical Reality: Total Landed Cost Is Harder Than It Looks

Total landed cost sounds simple until you try to implement it. Here's what makes it complicated.

The Multi-Echelon Problem

In a hub-and-spoke network, a single SKU might flow through multiple distribution centers before reaching stores. When Dallas orders frozen breakfast sandwiches, do those come directly from the supplier, or do they route through the San Antonio hub first?

The answer changes:

• Lead times (4 days supplier-to-hub, then 4 days hub-to-spoke, vs. 30 days direct)

• Transportation rates ($X per pallet per mile inbound from supplier vs. 1/2 $X between DCs)

• Holding costs (15% at regular DCs vs. 20% at the hub, which carries extra buffer stock)

• Handling costs (doubled at the hub because pallets are received and then picked again for outbound)

Every reorder decision at the spoke DC creates a demand signal at the hub, which creates its own reorder decision upstream. To model this, we couldn't just simulate inventory at one location.

We had to:

1. Aggregate the spoke DCs' replenishment orders into a new demand signal for the hub

2. Add the hub's direct store demand on top of that

3. Run a second simulation for the hub using this combined demand

4. Calculate costs separately for each echelon, then roll them up

The technical complexity wasn't in any single step. It was in sequencing them correctly so that the hub's costs reflected the actual demand it would face, not some theoretical average.

The Estimation Problem

Even with simulation, we needed cost inputs. The client provided summary financials—total transportation spend, total inventory value, total warehouse costs—but not SKU-level or lane-level rates.

We had to estimate:

Transportation cost per pallet-mile. The client's data showed the majority of shipments moved by truck, but total transportation miles could vary from 9 to 1,400 miles. We used grand averages: $X per pallet per mile. This worked for strategic comparison (hub-and-spoke vs. direct).

Holding cost percentage. We divided total warehouse costs by year-end inventory value across all RDCs to get 15%, an industry-standard figure. For the hub, we increased it to 20% to account for the additional buffer stock required. These were defensible estimates, but they assumed uniform cost structures across facilities. In reality, temperature storage, location, and ownership type (owned versus rented) play a huge part in variable costs.

Handling cost per pallet. We divided variable warehouse costs by full-pallet picks to get $X per pallet, then doubled it (inbound receiving + outbound picking). This ignored the complexity of partial-pallet picks, cross-docking, and labor productivity differences, but it gave us an order-of-magnitude number for the decision at hand.

The danger in estimation isn't the approximation itself; it's mistaking an approximation for precision. We documented every assumption, showed the client where better data would improve accuracy, and built the cost calculation as a modular function so the finance team could replace our estimates with actuals as they became available.

The Factorial Design: Understanding Tradeoffs

Once we could calculate cost accurately, we still had to find the right R and Q values. We eventually settled on simulation with factorial design. Run the simulation for every combination of R values (26 to 40) and Q values (1 to 21), generating 315 scenarios per SKU-location pair. Calculate cost and space for each, then plot the Pareto frontier. Expensive computationally but comprehensive.

Why This Matters for Your Next Project

If you're building a data science product in a messy organizational environment, here's what I'd carry forward:

The question isn't buy or build. It's how do we build the thing that shows people what they should buy. Enterprise platforms promise everything, but clients can't evaluate those promises without a working example in their own environment. Your prototype becomes the shared reference point that breaks the deadlock.

Show scenarios, not answers. The moment we stopped saying "the optimal R is 28" and started saying "here are 315 combinations; here's the Pareto frontier; which tradeoff reflects your strategy?" we stopped being vendors and became advisors. The tool didn't make the decision. It made the decision visible.

Total landed cost is a system problem, not a formula. You can't calculate it accurately without modeling the interactions between lead time, demand variability, reorder logic, and network structure. Simulation isn't overkill. It's the appropriate tool for a dynamic system.

And that's the real lesson: sometimes the best technical solution is the one that teaches the organization what questions to ask next.