A map with almost two million points on it:
and still fast on a phone in the field
A map with a few dozen pins is easy. A map with hundreds of thousands of points, several data layers, and a requirement to still work offline in the field is a different engineering problem. We've already solved it at scale: 1,940,996 sites rendered and searchable in a shipped Android GIS application.
What it is
Interactive maps and GIS (geographic information system) layers turn location data (points, regions, routes, historical overlays) into a map people can actually explore. They zoom, filter and search it, and in field applications, use it without an internet connection. The hard engineering problem isn’t drawing a map. It’s making one stay fast and usable once the dataset is large. That’s exactly where most off-the-shelf map embeds and naive custom builds break down.
When you need this (and when you don’t)
You need this when location is a core dimension of your data. A dataset of any real size needs to be explorable then, not just listed in a table. A research or heritage dataset with thousands to millions of sites fits. So does a logistics or field operations tool, or a real estate platform with meaningful location filtering. The same goes for any product where location matters as much as what is in it. Field use, offline requirements, or a dataset too large for a default map embed to handle well are the clearest signals you need a custom build.
You don’t need this if you’re placing a handful of pins on a map for a contact page or a store locator. A standard embedded map, Google Maps, Mapbox’s default widget, handles that without custom engineering.
How we build it
For most builds we use Mapbox GL or MapLibre for vector tile rendering. That’s what keeps large datasets fast. The map renders only what’s visible at the current zoom level. Clustering groups nearby points into a single marker, until you zoom in enough to see them individually. Data comes from your own PostgreSQL database with PostGIS for spatial queries, CSV or GeoJSON imports, or public sources like OpenStreetMap, Wikidata and national heritage or geographic registers. That’s the exact combination behind an archaeological atlas we built for a research institute. It covers 1,940,996 sites, assembled with a team of sixty AI research agents, and shipped as a production Android release.
For field applications, we build offline vector map support that caches relevant map tiles on-device. GPS-aware positioning and battery-conscious rendering round that out, so the app survives a full day of field use, not just a quick demo. Historical or alternate base layers, satellite imagery, archival maps, terrain, layer in where the use case calls for it. Search and filtering get built to stay fast at the real dataset size. We test against that real size, not against a sample of a few hundred points that hides the eventual performance problem.
What to watch
Dataset size decisions made early affect architecture choices later. A map built assuming a few thousand points will need real rework at a few hundred thousand. That’s why we ask for your actual or projected data volume before choosing a rendering approach, not after building the wrong one.
Offline map data also has a real storage cost on-device. A field app caching a large geographic area needs a clear policy on how much area and how much detail to cache. We size that against your actual field use case, rather than caching everything by default.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Interactive map | from $3,500 | Custom layers, filtering, search, clustering at real data volume | 5 to 7 weeks |
| Offline field application | from $9,000 | Offline vector maps, GPS field mode, routing, multiple base layers | 7 to 14 weeks |
Running cost is usually $20 to $150 a month in map tile and hosting fees, scaling with traffic and dataset size.
What this pairs with
Pairs with digital signage and kiosks for public-facing map displays, and with the analytics service for location-based reporting. See the development service page for the full build. For the real system this capability is proven on, see the archaeological atlas case study. It covers 1.94 million objects, offline vector maps, historical layers and field mode, shipped as a release-ready Android application.
Have location data that deserves to be explorable, not just listed? Get in touch and we will scope a map that holds up at your actual data size.
FAQ
How much does a custom interactive map cost?
From $3,500 for a map with custom layers from your own data, filtering and search, built for web or mobile. A full offline-capable field application with routing and multiple base layers typically runs $8,000 to $18,000, depending on dataset size and offline requirements. The archaeological atlas we built at 1.9 million points is a comparable example.
Can it handle a large dataset without slowing down?
Yes, this is specifically what we've proven at scale. Clustering, level-of-detail rendering, and vector tile techniques keep a map usable at hundreds of thousands to millions of points. Most naive map implementations fail because the browser or app tries to render every point at once.
Does it work offline?
Where the use case needs it, yes. Offline vector maps cache the relevant area on-device. A field researcher, a delivery driver, or anyone without reliable connectivity still gets a working map, not a blank screen.
Which data sources can feed the map?
Your own database, CSV or GeoJSON exports, or public sources like OpenStreetMap, Wikidata and national registers where relevant. That's the same combination we used to assemble close to two million archaeological sites for a research institute's atlas.
Web, mobile, or both?
Both are possible from a shared data layer. A web map on standard mapping libraries covers broad access. A native or React Native mobile app covers field use, where offline capability and GPS integration matter more than browser convenience.