Location based features power some of the most valuable software products in the market. Ride sharing, delivery logistics, real estate platforms, field service management, and social apps all depend on geolocation. But the technology stack for building location features is fragmented, and making the wrong choices early leads to expensive rewrites when you scale.
We have built location based systems for delivery tracking, geofenced notifications, store locators, route optimization, and interactive mapping interfaces. Here is a practical guide to the technologies involved and how to choose between them.
The Core Building Blocks
Every location based feature relies on some combination of five building blocks: geocoding, reverse geocoding, mapping display, geofencing, and spatial queries. Understanding what each one does helps you scope your project accurately.
Geocoding converts an address into latitude and longitude coordinates. When a user types "123 Main Street, Austin, TX" and you need to place a pin on a map, you are geocoding. This is an API call, not a client side operation, and every geocoding provider charges per request.
Reverse geocoding does the opposite: it converts coordinates into a human readable address. When a delivery app shows "Driver is near 456 Oak Avenue," it is reverse geocoding the driver's GPS coordinates. This is also a paid API call and is used heavily in tracking applications.
Map display renders an interactive map in your application. This includes tile rendering, zoom controls, pan gestures, marker placement, polygon drawing, and route visualization. The map is the most visible part of any location feature, and users judge your product's quality by how smooth the map experience feels.
Geofencing defines virtual boundaries around geographic areas and triggers events when a device enters or exits those boundaries. Delivery zones, restricted areas, and proximity notifications all use geofencing. This can run on the client (using device GPS) or on the server (using coordinate comparison).
Spatial queries search your database by geographic criteria. "Find all restaurants within 5 miles" or "Show all properties in this drawn polygon" are spatial queries. These require a database that supports geographic data types and spatial indexing.
Choosing a Maps and Geocoding Provider
The three major providers are Google Maps Platform, Mapbox, and Apple MapKit. Each has different strengths.
Google Maps Platform is the most feature complete option. It offers geocoding, routing, places search, street view, and the most accurate global address data. Pricing starts at $7 per 1,000 geocoding requests and $5 per 1,000 static map loads. The JavaScript API is mature but heavy. Google Maps is the right choice when you need the broadest global coverage and the most accurate address resolution, especially in regions outside North America and Western Europe.
Mapbox is the developer favorite. It uses open source map data from OpenStreetMap, offers highly customizable map styles, and provides a GL JS library that renders maps using WebGL for smooth 60fps performance. Pricing is more aggressive than Google: 100,000 free map loads per month, then $5 per 1,000 after that. Geocoding is $5 per 1,000 requests. Mapbox is the right choice when you need custom map styling, 3D terrain, or your application is map centric.
Apple MapKit JS is free for up to 250,000 map initializations per day, which makes it the cheapest option by far. The map quality has improved significantly since Apple rebuilt their maps data. However, MapKit JS has fewer features than Google or Mapbox, the documentation is thinner, and the developer ecosystem is smaller. It is a good choice for simple map displays in Apple centric products.
For most web and mobile applications we build, Mapbox is our default recommendation because of the developer experience, performance, and cost structure. We switch to Google Maps when the project requires places autocomplete with business details or needs coverage in regions where OpenStreetMap data is sparse.
Spatial Database Setup
Storing and querying geographic data requires a database that understands coordinates. The standard choice is PostgreSQL with PostGIS, and it is not close.
PostGIS adds geographic data types (points, polygons, lines), spatial indexes (R tree via GiST), and hundreds of spatial functions to PostgreSQL. It powers most location based applications in production today, from small startups to companies like Uber and Airbnb.
Key setup decisions:
Use the geography type, not geometry, for real world coordinates. Geography types use spherical math that accounts for the Earth's curvature, which means distance calculations are accurate at any scale. Geometry types use flat plane math and produce incorrect results over distances greater than a few hundred miles.
Create spatial indexes on every column you query by location. A query like "find all drivers within 2 miles" without a spatial index scans every row in your table. With a GiST index, the same query checks only the rows in the relevant spatial region. This is the difference between a 500ms query and a 2ms query on a table with 100,000 rows.
Store coordinates in SRID 4326 (WGS 84). This is the coordinate system used by GPS and every major mapping API. Storing in a different SRID creates conversion headaches throughout your application.
If you are building on Supabase, PostGIS is available as an extension you can enable with a single click. Combined with Supabase Realtime for live location updates, it is a powerful stack for location based features. We have also written about the broader PostgreSQL versus MongoDB decision, and geographic features are one of the strongest arguments for PostgreSQL.
Building Common Location Features
Store Locator or Nearest Location Search
The most common location feature. A user provides their location (via browser geolocation API or address input), and you return the nearest results sorted by distance.
The query in PostGIS is straightforward:
```sql
SELECT name, address,
ST_Distance(location, ST_SetSRID(ST_MakePoint(-97.74, 30.27), 4326)) AS distance
FROM stores
ORDER BY location <-> ST_SetSRID(ST_MakePoint(-97.74, 30.27), 4326)
LIMIT 10;
```
The `<->` operator uses the spatial index for a fast nearest neighbor search. This performs well up to millions of rows.
Geofenced Notifications
Triggering actions when a user enters or exits a defined area. For mobile apps, both iOS and Android provide native geofencing APIs that monitor regions in the background without draining the battery. For server side geofencing (tracking a fleet of vehicles, for example), you compare incoming GPS coordinates against stored polygons using PostGIS's `ST_Contains` function.
Server side geofencing scales better and gives you centralized control, but it requires devices to report their location at regular intervals, typically every 10 to 30 seconds for vehicle tracking.
Real Time Location Tracking
Showing moving objects on a map, like delivery drivers or field technicians, requires a combination of GPS reporting, a real time data channel, and smooth map animation.
The architecture is: device sends GPS updates to your server via API or WebSocket, server stores the latest position and broadcasts it to connected clients, and the map client animates the marker between position updates to create smooth movement. We cover the real time infrastructure patterns in our real time architecture guide.
The critical detail is update frequency versus battery life. GPS polling every second gives smooth tracking but drains a phone battery in hours. Polling every 30 seconds preserves battery but creates jumpy movement on the map. Most production apps use adaptive frequency: poll frequently when the device is moving, reduce frequency when stationary.
Route Display and Navigation
Displaying routes on a map requires a routing engine that calculates paths along road networks. Both Google Maps and Mapbox provide routing APIs that return polylines you can render on your map. Pricing is per request: roughly $5 to $10 per 1,000 route calculations.
For applications that need to calculate thousands of routes (logistics optimization, for example), using a hosted routing API becomes expensive. Self hosting a routing engine like OSRM (Open Source Routing Machine) or Valhalla with OpenStreetMap data eliminates per request costs. We have deployed self hosted routing for logistics applications where the volume justified the infrastructure investment.
Cost Considerations
Location features have variable costs that scale with usage, unlike most application features where server costs are relatively fixed.
- Geocoding: $5 to $7 per 1,000 requests. An app that geocodes on every search can rack up significant costs.
- Map tiles: $0 to $7 per 1,000 loads depending on provider and volume.
- Routing: $5 to $10 per 1,000 route calculations.
- GPS data storage: Real time tracking at 30 second intervals generates roughly 2,800 data points per device per day. For a fleet of 1,000 vehicles, that is 2.8 million rows per day.
Cache aggressively. Geocode results should be cached permanently since addresses rarely change. Route calculations between the same origin and destination can be cached for hours. Map tiles are cached by the browser automatically.
Budget these API costs into your software development budget from the start. We have seen teams surprised by $5,000 per month mapping bills that were not in their original projections.
Getting Started
If you are building a product with location based features, start by identifying which of the five building blocks you need. A store locator only needs geocoding, map display, and spatial queries. A delivery tracking app needs all five plus real time infrastructure.
Choose your mapping provider based on your primary use case, set up PostGIS for spatial data from day one, and plan for the API costs that come with geographic services.
Location features are inherently full stack work that touches mobile clients, web frontends, APIs, databases, and third party services. If you need help building location based features into your product, reach out to our team and we will scope the right architecture for your use case.