The US retail industry Is now running India's quick-commerce playbook from 2020
Heading into peak season 2026, one statistic stands out from the wave of US retail planning surveys published this year: 93% of retail logistics leaders say they're repositioning inventory closer to demand centers as a core resilience strategy, according to Kase's 2026 Peak Season Retailer Sentiment survey, reported by Sourcing Journal. Alongside carrier diversification and tighter 3PL integration, forward-deployed inventory is being framed as one of the year's defining moves, a hedge against tariff-driven demand volatility, unpredictable carrier capacity, and a peak season that increasingly starts before anyone has finished planning for it.
It's a sound strategy, and the surveys make a good case for why 2026 finally forced US retailers to take it seriously. But the underlying idea to put inventory as close to the customer as possible, in smaller, more numerous nodes, rather than a handful of large distribution centers hundreds of miles away, isn't new. India's quick-commerce sector didn't adopt this as a seasonal hedge. It built its entire operating model around it, permanently, starting around 2020, because ten-minute delivery simply doesn't work any other way.
What US retailers are calling a strategy, India called a prerequisite
The distinction matters more than it first appears. For most US retailers, forward-deployed inventory in 2026 is a response to a specific set of conditions where tariff volatility is pulling import schedules forward, carrier capacity tightening during peak, and demand is becoming harder to forecast on the traditional retail calendar. It's a real and reasonable adaptation, but it's fundamentally a hedge layered onto a network still organized around a relatively small number of large regional distribution centers.
India's quick-commerce operators never had that luxury of treating decentralization as optional. When the category's early players tried to fulfill ten-minute delivery promises using existing kirana store inventory and infrastructure, essentially borrowing capacity rather than owning it, the model broke down almost immediately, because inventory availability, store layout, and picking speed simply couldn't be controlled when the fulfillment infrastructure belonged to someone else. The fix wasn't a seasonal adjustment. It was rebuilding the entire fulfillment layer from scratch around small, company-owned "dark stores," which are micro-fulfillment centers stocking a curated few thousand fast-moving SKUs within a two- to three-kilometer radius of the customers they served, rather than a wide catalogue sitting in a warehouse an hour away.
Academic research on the phenomenon frames it as a genuinely novel piece of retail infrastructure, not an incremental tweak to existing distribution. A recent analysis in the California Management Review argues that India's dark-store model prioritizes proximity over visibility, speed over catalogue scale, and data over intuition, while Western retail was still largely debating omnichannel strategy layered on top of a traditional centralized network. The comparison is a useful corrective to the usual direction of the "what can market X learn from market Y" conversation: on this specific dimension, India built the infrastructure first, out of necessity, years before it became a defensive priority for US retail networks confronting a harder 2026.
Why the difference between "hedge" and "infrastructure" actually matters
This isn't just a matter of who got there first. Treating decentralized inventory as a temporary hedge and treating it as permanent infrastructure lead to genuinely different design requirements, and the gap between them is exactly where things tend to go wrong.
A hedge can tolerate some inefficiency because it's meant to be dialed up during a specific window and dialed back down afterward. Permanent decentralized infrastructure cannot, as every additional node is a new point of potential imbalance, running continuously, not just during a defined peak. India's quick-commerce operators have already run directly into this problem at scale. As competition intensified dark-store expansion across the market, one of the leading platform's own CFO acknowledged the strain publicly: pushing store rollouts ahead of schedule meant the network would have to carry a heavier load of underutilized stores, directly affecting near-term profitability for several quarters. Decentralizing fulfillment doesn't eliminate the capacity-matching problem that centralized networks already have to solve; it just multiplies the number of places that problem can show up, from a handful of large distribution centers to hundreds of small ones, each needing its own accurate replenishment signal.
This is the part of the India story that tends to get left out of the "look how fast they did this" narrative, and it's the part most relevant to US retailers now moving in the same direction. Forward-deploying inventory into more locations is the easy half of the decision. Keeping those locations correctly stocked, not overloaded with slow-moving SKUs, and not empty on the items actually driving demand that week requires a level of real-time, location-specific demand sensing that a network built around a few large DCs was never designed to produce. A retailer that decentralizes its footprint without building that underlying intelligence first is just distributing the same forecasting problem across more locations, each now too small to absorb a bad forecast the way one large DC could.
Two networks, five years apart
Picture two retail operations working through the same underlying problem, five years apart.
India, 2020: A quick-commerce operator launches dozens of small dark stores across a metro area, each stocked with a curated few thousand fast-moving SKUs, aiming for delivery inside ten minutes. Within months, the obvious failure mode shows up: some stores run out of the exact items driving that neighborhood's demand within hours of restocking, while others sit with slow-moving inventory nobody nearby is ordering. The fix isn't more stores but rather building real-time, store-level demand sensing that can tell the difference between a citywide trend and a hyperlocal spike and a replenishment engine that can act on that difference daily, not weekly. The operators who get this right scale into unicorns. The ones who treat it as a real estate rollout problem burn cash on underutilized locations for years.
US retail, 2026: A retailer facing tariff-driven import timing shifts and tighter peak-season carrier capacity decides to forward-deploy inventory into more regional nodes, closer to demand centers, following the same logic 93% of its peers are reportedly adopting. If that decentralization is treated purely as a network-design decision with more nodes, smaller radius, and closer to customers, without the corresponding investment in real-time, location-level demand visibility, the retailer is on a predictable path to rediscovering exactly what India's quick-commerce operators learned the hard way: more locations mean more places for a stockout or an overstock to hide, each invisible from a regional or national inventory report that was built for a handful of large DCs, not dozens of small ones.
The five-year gap between these two moments isn't really about who thought of decentralized inventory first. It's about which lessons from running that model at scale get absorbed before the rollout and which get relearned the expensive way, one underutilized node at a time.
What US retail networks should actually take from this
The genuinely useful lesson from India's experience isn't "open more forward-deployed nodes." It's that the infrastructure question and the intelligence question have to be solved together, not sequentially. A warehouse management system managing dozens or hundreds of smaller nodes needs real-time visibility into what's actually moving at each location, not a monthly or weekly replenishment cycle designed for a small number of large facilities. And a capacity and routing layer connecting those nodes to the delivery fleet serving them needs to treat the whole network as one shared system, the same principle that prevents a handful of overloaded hubs sitting next to underused ones in a traditional freight network, just applied one layer further down, at the level of dozens of small nodes instead of a few large ones.
This is precisely the design challenge Libera's warehouse management system and capacity and route planning engine are built around: real-time visibility across inbound, storage, and dispatch at every node, and a planning layer that evaluates capacity and demand across the whole network rather than location by location. The same logic extends across the full delivery journey through Libera's approach to all-mile logistics, coordinating first, mid, and last mile as one connected plan, which is exactly the kind of orchestration a genuinely decentralized fulfillment network needs to avoid trading one set of inefficiencies (a handful of overloaded DCs) for another (hundreds of unevenly utilized micro-nodes).
The real takeaway
US retail's 2026 shift toward forward-deployed inventory is a reasonable, evidence-backed response to a genuinely harder operating environment with tariff volatility, tighter carrier capacity, and a peak season that no longer follows a predictable calendar. But it's worth being honest about where this playbook has already been run at scale, under conditions that left no room for a slow rollout. India's quick-commerce sector didn't get a five-year head start by being more innovative in the abstract; it got there because the ten-minute delivery promise made the traditional centralized model mathematically impossible from day one, and it has spent those five years discovering exactly which parts of decentralization are genuinely hard: not the real estate, but the continuous, location-level demand intelligence needed to keep hundreds of small nodes balanced instead of trading a small number of large problems for a much larger number of small ones. That's the piece of the India story worth studying closely, well before the infrastructure itself is copied.
