Most "nearby" experiences still cheat: they draw a circle on a map and call it reachability. Isochrones flip that model: instead of "everything within X kilometres," you ask what area someone can actually reach in X minutes. Here's how we applied Google's Isochrones API in AroundMe.
Most “nearby” experiences still cheat.
They draw a circle on a map, query everything inside it, and call it reachability. That works until a river, a motorway junction, or a one-way system intervenes, and suddenly the café “ten minutes away” is twenty-five, while something further out as the crow flies is actually closer on the road.
Isochrones flip that model. Instead of “everything within X kilometres,” you ask: what area can someone actually reach from here in X minutes, given how they travel?
Google’s Isochrones API makes that question a product building block. This article explains what it is, how it works, where it creates business value, and how we applied it in AroundMe: a proof-of-concept that turns a natural-language prompt into places and events you can genuinely get to in time.
An isochrone (from Greek iso “equal” + chronos “time”) is a boundary of equal travel time. Points on the edge of the polygon take roughly the same time to reach from an origin under a given travel mode.
Compare that with a radius:
| Radius (distance) | Isochrone (time) | |
|---|---|---|
| Shape | Circle | Irregular polygon shaped by the road network |
| Question answered | “How far away?” | “How long to get there?” |
| Rivers / barriers | Ignored | Reflected in the geometry |
| Typical failure mode | False confidence | Slightly more complex filtering |
For consumer apps, logistics tools, and site-selection products, time is usually what users and operators actually care about. Distance is a proxy that breaks in the real world.
At a high level, you send Google an origin, a travel mode, a duration, and a travel direction. You get back a GeoJSON MultiPolygon representing a reachable area.
POST https://isochrones.googleapis.com/v1/isochrones:generate
Core parameters:
places/{place_id})travelMode: WALK, BICYCLE, or DRIVE (public transit is not supported)travelDuration: a Duration string such as "600s" (capped at 120 minutes; 60 minutes for DRIVE)travelDirection: FROM (outbound catchment) or TO (inbound / commute-to catchment)routingPreference: i.e. TRAFFIC_UNAWARE for stable planning polygons, or TRAFFIC_AWARE when live conditions matterenableSmoothing: softens jagged polygon edges for map displayThe API returns GeoJSON geometry (typically a MultiPolygon). That matters in cities: reachable areas can be disjoint islands (you can reach two neighbourhoods but not the blocked strip between them) and can include holes (inaccessible interiors).
Product implication: treat the response as a filter geometry, not a pretty outline only. Anything you discover afterwards (shops, depots, events) should be tested against that polygon (point-in-polygon), not merely against a bounding box.
Skipping step 3 is the classic bug: the map looks correct, but results leak in from unreachable corners of the bounding box.
Isochrones are valuable wherever “can we get there / serve there in time” beats “is it nearby on a ruler.”
Outbound (FROM) polygons answer: From this depot, which customers can we reach in a 30-minute SLA?
Teams use that for:
Unlike radius, the polygon follows the road network your drivers actually use.
Inbound (TO) polygons answer: Where can employees live and still reach the office in 45 minutes?
Useful for:
Retail brands often buy media or open stores against drive-time trade areas. Isochrones replace hand-drawn catchments with something reproducible and updatable, especially when you recompute under TRAFFIC_AWARE for peak hours.
Planners ask whether essential services are reachable within policy thresholds (e.g. “15-minute walk to a pharmacy”). Isochrones turn that from a slide-deck claim into a measurable layer.
This is where Around Me sits: help someone with limited time find something they can actually do before their next commitment, not something that merely looks close.
AroundMe is a thin POC built on our Spydr starter stack. The product promise is simple:
Tell us what you want to do and how long you can travel. We’ll show places and events inside the reachable area.
FROM, mode, clamped duration, smoothing on)Time over distance. A walk isochrone and a drive isochrone for the same “30 minutes” look nothing alike. The product UI always shows the polygon so users trust the filter.
1 hour’s walk 10 minute drive
Server-owned secrets. Isochrones, Places, and event APIs run from Route Handlers. The browser never sees web-service keys.
Honest limitations. The Isochrones API does not support transit. When someone asks for “by bus”, we surface that and fall back to a drive-time budget rather than inventing a tube network. Drive durations are clamped to the API’s 60-minute maximum.
Cheap search, expensive enrichment. We search broadly inside the bounding box, discard unreachable candidates with Turf point-in-polygon, then pay for Place Details / photos only for relevant results.
Natural language as the primary control. Seed prompts like “Quiet park within 10 minutes walk” double as product demos and regression fixtures for the parser.
The result is a small surface area with a clear story for stakeholders: radius lies; travel time doesn’t.
For businesses evaluating location-heavy products: if your users think in minutes, your backend should too. Isochrones turn a fuzzy “nearby” promise into a defensible product rule, useful in logistics SLAs, store catchments, and consumer trust.
For engineers: the API is approachable, one generate call, GeoJSON out, but the craft is in the surrounding system: clamping, FROM vs TO, traffic preference, MultiPolygon-aware filtering, and not overspending on details for unreachable candidates. Preview APIs also demand isolation (a thin client module) so request shapes can evolve without rewriting the product.
If you are exploring a travel-time product, or want a partner to prototype something like AroundMe on a modern Next.js stack, that is exactly the class of problem we like to ship: clear user value, real map constraints, and an implementation path from POC to production.
For years, open-weight models trailed the frontier by six months or more. Kimi K3 and GLM 5.2 change that - competitive benchmarks, million-token context, and pricing. Here's what product teams should know before picking a model.
Tom Sproull
In July 2026, OpenAI models escaped a sandboxed evaluation, exploited a zero-day vulnerability, and broke into Hugging Face's production systems, all to cheat a cybersecurity benchmark. Nobody directed them to. Here's what product and engineering teams should take from it.
Tom Sproull
If you think you'd be a good fit at Spydr, we'd love to hear from you!