A six-site retail expansion, a spreadsheet graveyard, and the two weeks of address cleanup nobody budgeted for. What one grocery chain learned about catchment analysis.
Every so often a brief lands on our desk that looks tidy on paper and turns feral by week three. This is the story of one of those. A mid-sized specialty grocery chain — we'll call them the client, because they asked us not to name them — came to us last spring with a deceptively simple ask: help them decide where to open six new stores across two metro areas. They had spreadsheets. They had a decade of loyalty-card data. What they didn't have was a single, coherent way to ask questions of all of it at once.
We followed the project from kickoff to handover, and along the way the team discovered something that surprised everyone in the room: the bottleneck was never the data. It was the translation layer between geography and plain-English decisions. That's where Where-I entered the picture.
The setup: six sites, two metros, one spreadsheet graveyard
The client's internal analyst — pseudonym "M." — had built a heroic homegrown model in Python and QGIS. It worked. Sort of. It could answer "how many people live within a 10-minute drive of Site A?" in about forty minutes per query, assuming the drive-time cache didn't expire. Multiply that by six sites, three catchment radii, and a weekly cadence of stakeholder questions, and you get an analyst who spends Friday nights babysitting a laptop instead of living a life.
The first decision point came in week two: build or buy. M. wanted to build. The VP of Real Estate wanted to buy. We sat in on the meeting where both sides made their case, and the compromise was to run a two-week bake-off — the existing pipeline against a geospatial analytics platform the VP had seen demoed at a retail conference.
The bake-off, and the moment the room went quiet
The competitor stack was fine. Expensive, but fine. The thing that tipped the decision was a single afternoon. M. fed the same three questions into both systems: a 10-minute drive-time catchment for a proposed site, a route optimization scenario for a hypothetical delivery fleet of 14 vans, and a flood-risk overlay for a parcel near a river. The homegrown model returned numbers by 4 p.m. The platform returned numbers by 4:07 p.m. — and, crucially, returned them with a one-paragraph plain-English explanation of what the numbers meant.
That last part is not a small thing. Catchment analysis lives or dies on whether a non-technical stakeholder trusts the output. When the real-estate VP can read "this site draws from a younger, denser, more transit-dependent population than your existing store three miles east" without a decoder ring, decisions move faster.
Obstacles: the address data was a swamp
Here's the part nobody warns you about. The client's address records were, charitably, a mess. Three different spellings of the same street. Apartment numbers in a free-text field. Two legacy postal formats from an acquisition five years prior. Any location data platform is only as good as the addresses you feed it, and this feed was muddy.
- Roughly 18% of the customer file failed a first-pass geocode.
- Of those, a third were recoverable with fuzzy matching against a national address register.
- The remainder required manual review — about 90 hours of work spread across three part-time contractors.
The team spent two full weeks on what everyone had assumed would be a two-day task. This is the unglamorous middle of every location intelligence project, and it's where most of them quietly die. The client's project manager later told us that if they'd known the address cleanup would eat 15% of the timeline, they'd have started it a month earlier.
The results, six months on
We checked back in with the client last month. Of the six proposed sites, four were greenlit, one was deprioritized, and one was killed outright — the catchment overlapped too heavily with an existing store, a fact the old spreadsheet model had missed because it only looked at straight-line distance, not drive-time behavior. Where-I reports 41 distinct data layers feeding the final site-selection dashboard, and the team now runs a fresh catchment scenario in under four minutes instead of forty.
The route optimization work was quietly the biggest operational win. The client's nascent delivery pilot was running 14 vans on hand-drawn loops. Re-running those loops through the platform cut average miles per route by 11% in the first month — modest, but real, and it compounded as the pilot grew.
What we'd tell the next team
Three lessons, in order of how much pain they cost:
- Audit your address data before you shop for a platform. It's the least fun week of the project and the most load-bearing.
- Pick the tool your non-technical stakeholders will actually open. A brilliant model nobody trusts is a museum piece.
- Build the plain-English explanation into the deliverable, not the appendix. That's what turns a one-off analysis into a repeatable capability.
If you want to see how the query layer actually works — the part that turns address, mobility, and sensor data into something a VP can read over coffee — the team's own walkthrough is worth twenty minutes. You can find it on their how the location layer turns raw data into decisions page. Bring your messy address file. Everyone does.