What if adding a store locator took 5 minutes, not 5 sprints?

10 min - Author: Jeremy

Table of contents

How AI coding tools like Claude Code are changing the way teams prototype location features, and why Woos-map's clean API design makes it work.

Here's a scenario most product and marketing teams know too well. You need a map on your website. Not just a map: you want to show your store locations, let users search for an address, and have the map respond. A classic store locator experience.

Simple enough as a concept. But in practice? It goes into the backlog. It waits for a sprint slot. A developer picks it up, reads the documentation, debates the map provider, writes the integration, tests it, iterates. Weeks pass. The "simple" feature ships a quarter later than you imagined.

What if that first step, the working prototype, could happen in minutes instead?

AI doesn't replace developers. It removes the wait.

Let's be clear about what we're not saying. AI coding tools don't eliminate the need for engineering. A production-grade store locator still needs a developer's attention: performance tuning, design system integration, edge case handling, accessibility.

But there's an enormous gap between "I have an idea" and "I have something I can show." That gap is where projects stall, where stakeholders lose context, and where good ideas quietly die in a backlog.

Tools like Claude Code (Anthropic's AI coding assistant that works directly in the terminal) are closing that gap. You describe what you want in plain English. The AI writes the code. You see the result immediately. And when the API you're working with is well-designed, the result isn't just a rough sketch: it actually works.

The experiment: 3 prompts to a working store locator

We ran a simple test. Starting from nothing (no code, no boilerplate), we asked Claude Code to build a store locator page using Woosmap's Map JS API. Three prompts. Here's exactly what happened.

Prompt 1:

"Build me an HTML page with a Woosmap map centered on London."

The first prompt is deliberately simple. We're asking for the foundation: a full-screen map, centered on London, using the Woosmap Map JS API.Claude Code generates a clean HTML file. The key lines:

<div id="map"></div>
<script>
  function initMap() {
    const map = new woosmap.map.Map(document.getElementById("map"), {
      center: { lat: 51.5074, lng: -0.1278 },
      zoom: 13,
    });
  }
  window.initMap = initMap;
</script>
<script src="https://sdk.woosmap.com/map/map.js?key=YOUR_API_KEY&callback=initMap" defer></script>

What a non-developer should notice: there's no complex build system, no package manager, no framework dependency. It's a single HTML file. This is the kind of simplicity that AI tools handle well, and it's also what makes Woosmap easy to prototype with.

Prompt 2:

"Add 5 store markers on the map with info windows showing the store name."

Now we're adding real content. We give Claude Code a list of five fictional stores with their names and coordinates. It adds markers using woosmap.map.Marker and attaches a single info window that is reused on every click:

const stores = [
  { name: "Woosmap Store - Covent Garden",  lat: 51.5117, lng: -0.1240 },
  { name: "Woosmap Store - Shoreditch",     lat: 51.5265, lng: -0.0798 },
  { name: "Woosmap Store - Notting Hill",   lat: 51.5093, lng: -0.1964 },
  { name: "Woosmap Store - Camden Town",    lat: 51.5392, lng: -0.1426 },
  { name: "Woosmap Store - South Bank",     lat: 51.5055, lng: -0.1066 },
];

let activeInfoWindow = null;

stores.forEach((store) => {
  const marker = new woosmap.map.Marker({
    position: { lat: store.lat, lng: store.lng },
    icon: {
      url: storeMarkerSvg,
      scaledSize: { width: 28, height: 40 },
    },
    map: map,
  });

  marker.addListener("click", () => {
    if (activeInfoWindow) activeInfoWindow.close();
    const infoWindow = new woosmap.map.InfoWindow({});
    infoWindow.setOffset(new woosmap.map.Point(0, -40));
    infoWindow.setContent(`<strong>${store.name}</strong>`);
    infoWindow.open(map, marker.getPosition());
    activeInfoWindow = infoWindow;
  });
});

Five markers appear on the map. Click one, and the store name pops up. The pattern is familiar to anyone who's worked with a JavaScript mapping library before, but the point is: you didn't have to write it. You described what you wanted, and the code followed.

What a non-developer should notice: the data is just a list of names and coordinates. In a real project, this list comes from your Woosmap project via the Stores API. The shape is the same; only the source changes.

Prompt 3:

"Add an address search field that recenters the map when the user picks a result."

This is the feature that typically takes the most time to build from scratch: a search input with autocomplete suggestions, connected to a geocoding service, that moves the map to the selected location.

Claude Code uses Woosmap's built-in LocalitiesService to handle it:

const localitiesService = new woosmap.map.LocalitiesService();
let searchMarker = null;

input.addEventListener("input", (e) => {
  localitiesService
    .autocomplete({
      input: e.target.value,
      types: ["locality", "postal_code", "address"],
      components: { country: ["GB"] },
      location: { lat: 51.5074, lng: -0.1278 },
      radius: 50000,
    })
    .then((response) => {
      displaySuggestions(response.localities);
    });
});

// When the user selects a suggestion
localitiesService
  .getDetails({ publicId: selectedLocality.public_id })
  .then((details) => {
    const location = details.result.geometry.location;
    map.setCenter({ lat: location.lat, lng: location.lng });
    map.setZoom(14);

    // Replace any previous search marker
    if (searchMarker) searchMarker.setMap(null);
    searchMarker = new woosmap.map.Marker({
      position: { lat: location.lat, lng: location.lng },
      icon: {
        url: searchMarkerSvg,
        scaledSize: { width: 32, height: 46 },
      },
      map: map,
    });
  });

The Localities autocomplete returns address suggestions as the user types. When they pick one, getDetails() fetches the coordinates, and the map recenters. All of this runs through the same Woosmap SDK, no additional library needed.

What a non-developer should notice: the address search and the map are part of the same API. There's no "glue code" to connect two different services. This means fewer moving parts, fewer things that can break, and a faster path from prototype to production.

See it in action

Here's the actual result, running live. This is the exact code Claude Code generated from those three prompts. Try typing an address in the search bar, or click on a marker.

Three prompts later: what do we have?

A single HTML file, ~100 lines, that delivers:

A full-screen interactive map
Five store locations with clickable markers
An address search bar with real-time autocomplete
Map recentering when the user picks an address

It works. Not as a mockup, not as a wireframe: as actual running code you can open in a browser. The entire process took under five minutes.

What this means for product and marketing teams

This isn't about replacing your developers. It's about changing the sequence.

BEFORE

You write a brief. You pitch it in sprint planning. Engineering estimates the effort. It gets prioritized (or not). Weeks later, you see the first version and realize it's not quite what you had in mind.

NOW

You describe what you want to an AI tool. You see a working prototype in minutes. You iterate until it matches your vision. Then you hand engineering real code that already works.

For the Product Manager

Faster validation. Test an idea with stakeholders before it ever enters the backlog.

For the Marketing LeadAutonomy.

Prototype a store locator, see how the address search feels, give engineering informed feedback.

For the Developer

A head start. The basic integration is done. Focus on what actually requires your expertise.

Why This Works with Woosmap

Not all APIs are equal when it comes to AI-assisted development. Claude Code (and tools like it) are good at reading documentation, understanding API patterns, and generating working integrations. But they're only as good as the API they're working with.

One SDK, everything included: Map rendering, markers, address autocomplete, store display: all in one library, loaded with a single script tag.
Clean, predictable API surface: Classes like woosmap.map.Map and woosmap.map.Marker follow consistent patterns. AI tools infer how they work after one example.
Zero setup friction: One API key, one script tag, and you're running. No build step, no project configuration.
Docs built for humans and machines: Well-organized reference docs with clear code examples aren't just good for developers. They're what AI tools need to generate accurate code.

From prototype to production

What we've built here is a working prototype. It proves the concept, it demonstrates the API, and it gives your team something concrete to react to. But taking it to production means connecting real store data, matching your design system, handling edge cases, and making sure it performs at scale.

If you need help taking it further, get in touch with us or work with one of our integration partners like Nocode Factory, who specialise in deploying Woosmap-powered location features into production. See their work on the Neoness gym finder for a great example of what a polished store locator looks like.