Put a store locator on a website and the default path is well worn: a Google Maps embed, an API key, a billing account, and a usage meter that runs for as long as the site exists. For what the visitor actually needs, an answer to where can I buy this near me, that is a lot of standing infrastructure.
Keys are also a liability out of proportion to their job. They leak into client-side code, they have to be restricted to the right domains, they get rotated when staff changes, and the invoice scales with popularity. A locator that succeeds gets more expensive precisely because it succeeded.
A manufacturer we build for sells through a distributor network: 89 locations, every one of which needed to appear on an interactive map and in a searchable list. We shipped the whole thing with zero API keys and zero monthly bill, and with pins that stay clickable even when several distributors share one building. Here is how.
Geocode once, at build time
The starting insight is that distributor addresses barely change. Geocoding them fresh for every visitor, which is a large part of what a maps API key pays for, is waste. So the geocoding happens once, in a build-time script. It resolves all 89 addresses to coordinates, writes them to a JSON file, and the live site only ever reads that file. No geocoding happens at runtime, ever.
That single decision removes the entire operational surface of a typical locator. There is no key to provision, no billing account to monitor, and no quota to think about, because the only geocoding requests ever made happen on our side, at build time, a handful of times a year.
The map itself is Leaflet, the open-source mapping library, drawing OpenStreetMap tiles. No key, no quota, no vendor account, no terms-of-service change that can break the feature next year. Pins, popups, and zoom-to-fit come from code the client owns a copy of, not a service they rent.
Free infrastructure deserves good manners
For the geocoding we used Nominatim, OpenStreetMap's free geocoder, and free does not mean careless. The service publishes a usage policy, and the script follows it: it identifies itself with a descriptive user agent, waits at least 1.1 seconds between requests, and caps itself at two queries per distributor.
When an address cannot be resolved, the script falls back to the real centroid of the distributor's state, province, or country. A pin in the right region, honest about its precision, beats a fabricated street position. The fallback is never invented, which is the same rule we hold everywhere else: unknown stays unknown.
The golden-angle spiral
One stubborn problem remained. Some distributors share an address, or resolve to identical coordinates, and stacked pins are unusable. The top pin swallows every click, and a visitor never discovers the businesses underneath it.
The fix comes from botany. Exact-duplicate coordinates fan out along a tiny spiral built on the golden angle, the packing pattern sunflowers use to fit seeds without overlap. Each duplicate pin steps a little further around the spiral, so all of them stay individually visible and clickable while still reading as one location on the map.
The golden angle works because it never repeats. Step around a circle by roughly 137.5 degrees each time and no two points land on the same radial line, which is why the pattern spreads evenly no matter how many duplicates pile onto one address. Two pins or ten, the cluster stays readable.
What the finished locator does
- An interactive map with markers and popups for all 89 distributors, no API key anywhere
- Text search across name, city, and country, with results grouped by region
- A live count, showing X of 89, so filtering is never a mystery
- The list and the map track the same filtered set, and the map re-fits its bounds as results narrow
- An accessible empty state when a search matches nothing
The bill that never arrives
Because the coordinates ship inside the build, there is nothing to go down and nothing to invoice. No key to rotate when an employee leaves, no surprise pricing email when traffic grows, no third-party outage that blanks the map on a busy Monday. The locator costs what static files cost, which rounds to nothing.
There is a speed dividend too. The map data is a local file, not a runtime API call, so the locator renders without waiting on anyone else's servers.
Not every map should be built this way. Live vehicle tracking, live inventory, or thousands of points that move daily justify a paid platform. But a distributor network that changes a few times a year is static data wearing a map costume, and static data is the cheapest, fastest, most reliable thing on the web. When a distributor does change, the client tells us, the script reruns at the next build, and the map is current again.
