When we started building Replengrove in 2024, the first question we had to answer wasn't about algorithms or integrations -- it was about who we were building for. There's a wide spectrum of retailers who have inventory forecasting problems, from single-location boutiques to enterprise chains with hundreds of stores and dedicated supply chain teams. We chose to focus on multi-store retailers with 3-15 locations. This is why.
The Single-Store Problem is Already Solved
A single-location retailer with an inventory problem has a lot of options. There are dozens of lightweight inventory management tools designed for one-store operations. The workflows are simpler: one set of demand signals, one receiving dock, one buyer making one set of decisions. The manual spreadsheet approach, while imperfect, scales to one location with manageable effort. The problem is real but the tools exist.
We weren't going to build a better single-store inventory tool. The market is reasonably served, and the problem, while genuinely difficult, is well-understood and addressed by multiple existing solutions.
The Enterprise Problem Is a Different Business
At the other end of the spectrum, enterprise retail chains with 50+ locations face inventory forecasting problems of enormous complexity. They have dedicated demand planning teams, ERP systems from major vendors, complex supply chain networks, and enough volume to justify significant technology investment. Their problems are real and hard, but they're being addressed by enterprise software vendors with implementation teams and multi-year contracts.
Building for that market requires a different kind of company -- large sales teams, lengthy enterprise sales cycles, integration with legacy ERP systems, and a product roadmap driven by large-customer feature requests. That wasn't the company we wanted to build, at least not at this stage.
The Middle Market Has No Good Answer
Between those two poles is a significant population of retailers that existing tools underserve: multi-store chains with 3-15 locations, often independently owned or family-operated, running somewhere between $3M and $30M in annual revenue. These retailers are too large for single-store tools -- they have location-specific demand variation that makes chain-level forecasting genuinely inadequate -- and too small for enterprise solutions, which typically require budget and implementation resources beyond what an independent operator can justify.
The buyer at a 7-location specialty grocery chain is managing a real complexity problem. They have different velocity patterns across different neighborhoods. They have multiple suppliers with different lead times and delivery schedules. They need purchase orders that are right for each location, not just the chain average. And they're doing all of this with a spreadsheet that was built for one person's workflow and doesn't survive that person taking a vacation week.
When we talked to buyers in this segment while developing Replengrove, the consistent themes were: manual processes that don't scale, recurring stockouts on high-velocity products, overstock in categories where they're ordering to a chain average that overstates demand at lower-velocity locations, and buyer time dominated by order mechanics rather than the category decisions that actually drive business performance. These were not unique to any one retailer. They were structural problems with the available tools.
Why Multi-Store Specifically Changes the Problem
We didn't choose multi-store retailers as our focus because of market sizing alone. We chose them because the multi-store context fundamentally changes what a good forecasting solution needs to do.
A single-store retailer needs a tool that tracks velocity and tells them when to reorder. That's genuinely useful, and the existing solutions provide it reasonably well.
A multi-store retailer needs a tool that tracks velocity at each location independently, recognizes that the same SKU moves differently at different locations, generates purchase orders that reflect those differences, and does all of this without requiring the buyer to manually maintain 3,000-plus inventory positions in a spreadsheet. That's a substantially harder problem, and it's the problem we set out to solve.
The store-level demand sizing approach that Replengrove is built around -- independent time-series models per location per SKU, updated continuously from POS sell-through data -- is specifically designed for the multi-store context. It doesn't make sense for a single-location operator. It makes complete sense for a buyer who's trying to order the right amount for five locations that all have different demand patterns for the same product.
What We Learned From Early-Access Retailers
Our early-access pilot program launched in early 2025 with a small group of multi-location independent retailers in the Minneapolis area. What we learned confirmed the market fit but also surfaced the specific operational details that matter most to this buyer segment.
First: the POS integration is the make-or-break factor. Buyers who connected their POS data directly saw immediate value. Buyers who were uploading CSVs manually found the overhead acceptable for a few weeks but wanted automation as soon as the tool proved itself. Getting the data pipeline right is the foundational step -- everything downstream depends on it.
Second: buyers don't want a black box. They want to understand why the system is recommending what it recommends, and they want to be able to override it easily when their knowledge of context -- an upcoming promotion, a supplier change, a local event that will spike demand -- tells them the forecast is missing something. Transparency in the recommendation logic builds trust faster than accuracy alone.
Third: the time savings are real and they appear quickly. Most buyers in our pilot saw meaningful reduction in order construction time within the first two weeks. The time they recovered didn't go to leisure -- it went to category decisions, vendor conversations, and the kind of strategic planning that a spreadsheet-dominated workflow had been crowding out. That's the value proposition we were building toward, and seeing it materialize in the pilot validated the direction.
Multi-store first wasn't a market positioning decision. It was a technical decision about what problem we could solve with genuine specificity, and a conviction that the buyers managing those operations deserved tools that actually fit what they do.
