Autonomous agents built an EV charging app in under a day

# 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, live-status pins, 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 live in a phone frame on [Built with MapMap](/built-with-mapmap), and you can use it right there.

## 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 live availability
- 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 live 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 live 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 live status |
| 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:

```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](/docs/maps). 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](/news/mapmap-nav).

## 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](/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](/news/maps-for-ai). 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](/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](/docs/maps) 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](/agents).