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, one we have already solved 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: zoom, filter, search, and in field applications, use without an internet connection. The hard engineering problem is not drawing a map, it is making one stay fast and usable once the dataset is large, which is exactly where most off-the-shelf map embeds and naive custom builds break down.
When you need it (and when you do not)
You need this when location is a core dimension of your data and a dataset of any real size needs to be explorable, not just listed in a table: a research or heritage dataset with thousands to millions of sites, a logistics or field operations tool, a real estate or property platform with meaningful location filtering, or any product where “where” is as important a question as “what.” 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 do not need this if you are 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, which is what makes large datasets stay fast: the map renders only what is visible at the current zoom level, with clustering that 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, the exact combination behind an archaeological atlas we built for a research institute covering 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 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 are built to stay fast at the real dataset size, tested against it, 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, which is why we ask for your actual or projected data volume before choosing a rendering approach, not after building the wrong one.
Offline map data has a real storage cost on-device, and a field app caching a large geographic area needs a clear policy on how much area and how much detail to cache, which we size 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.
Related
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: 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, comparable to the archaeological atlas we built at 1.9 million points, typically runs $8,000 to $18,000 depending on dataset size and offline requirements.
Can it handle a large dataset without slowing down?
Yes, this is specifically what we have proven at scale: clustering, level-of-detail rendering, and vector tile techniques keep a map usable at hundreds of thousands to millions of points, rather than the browser or app choking on rendering every point at once, which is where most naive map implementations fail.
Does it work offline?
Where the use case needs it, yes: offline vector maps cache the relevant area on-device, so a field researcher, a delivery driver, or anyone without reliable connectivity still has a working map rather than 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, 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 built on standard mapping libraries for broad access, and a native or React Native mobile app for field use where offline capability and GPS integration matter more than browser convenience.