When you need this

Where a thing is decides whether a customer comes. Branches, dealers, pick-up points, service areas, congregations, finished projects. The usual answer is an embedded map with pins dropped by hand: fine at five locations, unusable at fifty, and wrong the first time a branch moves.

What I actually build

Each location as a record your staff edit — address, hours, phone, whatever the place really has. The map reads from those records, so a change made in the office is a change on the map, with no developer in the loop.
Pins that group by district and split apart as you zoom, so a hundred and forty points do not freeze a mid-range phone.
A search and a list beside the map, kept in step with it. Most people use the list; the map earns its place by making the list understandable.
The page still answering when the map cannot load: an ordered list with addresses and links. Maps fail — a blocked script, a lapsed key, a phone on data-saver — and the customer still needs the nearest branch.
The map provider chosen on cost before we start. Google bills per map load once traffic passes its free allowance, and a directory people open every weekend can pass it. Often a free provider does the job.

Where this shows up in my work

One hundred and forty-two churches on one map: congregations grouped by district on the map, a live search beside it for people who already know the name of the town, and all of it kept current by a union whose staff do not build websites.

What you get

A map that stays right because it is fed by records your team already keeps, a page that still answers when the map does not, and no monthly bill you were not told about before the work started.