Skip to content
Log inGet an API key
news / agents-built-ev-app · raw .md
Agents5 min readMapMap engineering
Concentric isochrone rings radiating from small charge-point nodes on a faint tile grid, with a single route line linking two of the nodes.

An EV charging app built on the public MapMap SDK

Note, updated 23 September 2026. MapMap now has native EV routing. POST /v1/ev/plan and the plan_ev_route MCP tool shipped on 1 September 2026 and have answered on the hosted gateway since 6 September: a physics consumption model over the route and charge stops timed against the vehicle's charging curve. The app in this post predates them, and its range ring is still a plain isochrone. See the EV route planning guide.

Updated 17 October 2026. This post was first titled as if agents built the app on their own and quoted a build time we had not measured. We decided what to build and own the result; agents did the implementation. The title and the wording below now say that.

A working EV charging app for a nationwide UK rapid-charge network, with 909 real sites, availability pins drawn from a dated snapshot, a range ring and turn-by-turn routing to a chosen charger, was built on the MapMap SDK and gateway, with coding agents doing the implementation and us deciding what to build. It is not a mockup: the real app runs in a phone frame on Built with MapMap, and you can use it right there. The mapping, routing and reachability are live calls to our gateway. The availability, the tariffs and the charge session are not, and the honest list further down says exactly what that means.

What is in the app?

A full consumer charging app, not a map with pins on it. The feature list is the one drivers ask for and charging apps get criticised for missing:

  • 909 real UK rapid-charge sites on a branded vector basemap, clustered, with pins colour-coded by availability from the snapshot
  • Filters for available-only and ultra-rapid (150 kW+), postcode and town search, and a one-tap jump to the nearest usable charger
  • A charger detail sheet with the site's recorded status, per-connector power, transparent peak and off-peak pricing, and a predicted-availability read for when you would actually arrive
  • A range ring drawn from the current battery percentage, with a count of chargers inside it
  • One-tap routing to a chosen charger with an arrival-battery estimate
  • A simulated charge session with kWh and cost ticking up, a charge-complete alert and an idle-fee warning before overstay fees start
  • A globe projection at altitude that flattens to a normal map as you zoom in

The app is a Vite web build embedded in a phone frame. Map rendering is © OpenStreetMap contributors.

How much of it is MapMap?

All of the mapping, routing and reachability, which is the point of the exercise. The app assembles a specialised product from general-purpose primitives:

App featureMapMap primitive
Branded vector basemap@mapmap/maps
Clustered, status-coloured pinsPlacesLayer with a colour match on the status field
Route line to a chargerRouteLayer over GET /route/v1/{profile}/{coordinates}
Driver position puckPositionPuck
Range ringPOST /isochrone

The client code is the same shape any customer would write:

js
import { createMap, RouteLayer, PositionPuck } from "@mapmap/maps";

const map = createMap({ container, apiKey });
const routes = new RouteLayer(map);
const puck = new PositionPuck(map);

Everything above is in the maps SDK docs. There are no private endpoints in the app and no internal branches of the SDK: it was built the way an outside developer would build it, which is the same discipline we used when we built a full navigation app on MapMap.

Why does it matter that agents did the implementation?

Because it is the strongest evidence we can offer for a claim we make a lot: that MapMap is buildable by software, not just documented for humans. The platform publishes llms.txt, machine-readable pricing, an MCP server with routing and styling tools, and one-call key issuance, and we have written before about agents using the API with no human in the loop. This app is the next step up from calling an API: we pointed coding agents at the public docs and the published npm package, and they implemented a product on top.

The build covered the map, the seeded site data, the charge-session flow and the embed. A second showcase entry, a low-bridge capture app aimed at the UK's bridge-strike problem, was built the same way and sits on the same page.

What it does not do

An honest list, because the gap between a demo and a product is exactly what a buyer needs to know.

  • When this was written MapMap had no native EV routing. The range ring is a standard isochrone from POST /isochrone, and the arrival-battery estimate is arithmetic in the app, not an energy model in our engine. For consumption-aware EV routing, use POST /v1/ev/plan (see the note above) rather than building the layer yourself the way this app does.
  • Availability and pricing are seeded snapshot data, not a live operator feed. The session flow is simulated. Wiring a real CPO backend is integration work the agents did not do.
  • The app is a demo. It is not affiliated with or endorsed by any charging network, and it is not in an app store.
  • Nearest-charger selection is straight-line distance in the client. For drive-time ranking you would use POST /matrix, which bills one call per started block of 25 elements.

Try it

Use the app in the phone frame on Built with MapMap: pan the map, tap a charger, hit Nearest, open the range ring. If you want to build the same shapes yourself, the maps SDK docs cover every primitive in the table above, and a verified email gets you 50,000 free calls a month with commercial use allowed. If your builder is an agent rather than a person, start it at /agents.

ShareXLinkedInHacker NewsRedditEmail