Autonomous agents built an EV charging app in under a day
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 by autonomous coding agents in under a day on the MapMap SDK and gateway. 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 did the agents actually build?
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 feature | MapMap primitive |
|---|---|
| Branded vector basemap | @mapmap/maps |
| Clustered, status-coloured pins | PlacesLayer with a colour match on the status field |
| Route line to a charger | RouteLayer over GET /route/v1/{profile}/{coordinates} |
| Driver position puck | PositionPuck |
| Range ring | POST /isochrone |
The client code is the same shape any customer would write:
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 built it?
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: coding agents were pointed at the public docs and the published npm package, and shipped a product on top.
Under a day covers the whole build: 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.
- MapMap has 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. If you need consumption-aware EV routing, you are building that layer yourself on top of our routing, 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.