Cost to add maps to an app: Google, Mapbox and OSM

The cost to add maps to an app is the clearest example of a feature where the quote you get and the bill you pay are answering different questions. There is the engineering work to put a map inside your product, which for most apps lands between £4,000 and £30,000. And there is a usage charge that starts small, stays invisible through beta, and turns into a monthly line item at exactly the point your product starts working.

Google reshaped that second number in March 2025 when it replaced the long-standing flat monthly credit with per feature free caps. Plenty of budgets written before that change no longer describe reality. This guide separates the build from the running cost, compares the three realistic options in 2026, and shows where each one stops making sense.

What does the cost to add maps to an app come to?

The cost to add maps to an app is a one off build plus a per request usage fee. A simple map with markers typically costs £4,000 to £8,000 to build. Search, routing and marker clustering push it to £8,000 to £18,000. Live tracking of moving vehicles with estimated arrival times sits at £18,000 to £30,000. The usage fee depends on which provider calls you make and how many, and it is normally free at low volume.

The shape matters more than the exact figures. A feature whose cost rises with usage needs a per user economic answer before launch rather than after, and most teams shipping maps have never done that sum. This is the same structural problem we described for the cost of adding video calls to an app, and it catches people out for the same reason.

The build, by scope

The gap between the first two rows is mostly the search box. Place autocomplete that feels instant, handles UK postcodes properly, and does not fire a paid request on every keystroke is more work than it looks, and it is where most of the usage bill originates too.

The gap between the second and third rows is battery. A map that shows where a driver is right now needs background location, and background location on both iOS and Android is a set of platform-specific rules about permissions, accuracy modes and update intervals. Getting a live tracking feature that does not drain a phone by lunchtime is genuinely difficult engineering.

The three realistic options in 2026

Google Maps Platform

Google is the default and, for consumer-facing products in the UK, usually the right one. The map matches what users already have on their phone, the place data is the best available, and the SDKs are mature.

The pricing changed materially in March 2025. Google replaced the flat 200 US dollar monthly credit with free usage caps applied per SKU, so each individual feature you use gets its own allowance rather than sharing one pot. Essentials tier SKUs get 10,000 free events a month each, Pro gets 5,000 and Enterprise gets 1,000, with Essentials Map Tiles APIs going as high as 100,000 calls at no cost per SKU per month. Beyond the free caps, published rates run from about 2 to 40 US dollars per 1,000 requests depending on the SKU, the tier and your monthly volume, as set out in Google’s pricing and billing overview.

That change helps and hurts different apps. An app that renders a map and does nothing else is better off, because one SKU with a 10,000 event allowance covers a lot of early usage. An app that renders maps, autocompletes addresses, geocodes them, and requests routes is using four SKUs at four different tiers, and the old single credit used to absorb all of that together.

Google also introduced subscription plans as an alternative to pay as you go, with a Starter plan at 100 US dollars a month for 50,000 calls and an Essentials plan at 275 US dollars a month for 100,000 calls. For a product with predictable volume, the subscription removes the thing founders actually hate about usage pricing, which is not the amount but the uncertainty.

Mapbox

Mapbox is the strongest option when the map is part of your brand rather than a utility. The styling control is genuinely better, the vector rendering is excellent, and you are not shipping a Google-shaped map inside a product you have designed carefully.

Pricing is purely usage based with no flat subscription. Web maps include 50,000 free map loads a month, where a load is one map initialisation and unlimited interaction within that session, then 5 US dollars per 1,000 loads up to 200,000 and 3 US dollars per 1,000 above that, according to Mapbox’s published pricing. Mobile maps bill differently, on monthly active users rather than loads, and the navigation products have their own free tiers that are considerably tighter.

That web session model is the important detail. If your users open a map once and then pan, zoom and interact for ten minutes, Mapbox bills one load and Google bills per interaction with certain SKUs. For a dashboard style product with long sessions, that difference is large enough to decide the question on its own.

OpenStreetMap with MapLibre

The open source route uses OpenStreetMap data rendered through MapLibre. The data is free and openly licensed, which is the part everyone knows. The part people miss is that serving tiles is not free, and the public OpenStreetMap tile servers have a usage policy that explicitly excludes production application traffic.

So you either pay a commercial tile host, which puts you back into usage pricing at a generally lower rate, or you run your own tile infrastructure. Running your own is viable and we have done it, but it means a rendering pipeline, storage, a CDN, style maintenance and a geocoder, because OpenStreetMap does not come with address search attached. Budget it as a small ongoing engineering commitment rather than a one off saving.

This route makes sense in two situations: very high map volume where the usage bill has become a genuine cost centre, and products with a data residency or vendor independence requirement that rules out the commercial providers. It rarely makes sense for an MVP.

Where the usage bill actually comes from

In almost every project we have audited, the map itself is a minority of the cost. The bill comes from three places.

Autocomplete on every keystroke. A user typing “14 Deansgate Manchester” generates twenty-two requests if you fire on every character. Debounce the input to fire after a pause, set a minimum character count, and use session tokens where the provider offers them so a search and its final selection bill as one unit. This single change routinely cuts a maps bill by 80% or more.

Geocoding the same addresses repeatedly. Addresses do not move. If you geocode a customer’s delivery address on every order, you are paying for the same answer indefinitely. Cache the coordinates against the address record and geocode once.

Recalculating routes too often. A live tracking feature that recalculates the route every five seconds is spending money to tell the user something that changed by forty metres. Recalculate on meaningful deviation, not on a timer.

There is a fourth, quieter one: development and testing traffic hitting the same billing account as production. Separate the keys, apply restrictions, and set a budget alert on day one rather than after the first surprising invoice.

Which to pick, in one paragraph each

Choose Google if you are building a consumer product in the UK where place data quality and familiarity matter, or if you need reliable business listings and reviews. Accept that you will need to manage SKU usage deliberately.

Choose Mapbox if the map is a designed part of your product, if your users have long interactive sessions on the web, or if you want predictable styling control. Check the mobile monthly active user model against your expected audience before committing, because it favours products with high usage per user and penalises products with many occasional users.

Choose OpenStreetMap with MapLibre if you have high volume, a strong reason to avoid vendor dependency, or a data residency requirement. Do not choose it to save money on an MVP, because you will spend the saving on operations.

What to do before you commit

Estimate your requests before you pick a provider, not after. Take your expected monthly active users, multiply by how many times each opens a map, and add a realistic number of searches per session. Then price that against each provider’s current published rates. It is a twenty-minute spreadsheet and it changes the answer surprisingly often.

Then instrument it. Log map and geocoding calls from the first internal build so you can see the real ratio between users and requests, which is almost never the ratio you assumed. That habit is the same one that keeps every usage-priced feature honest, and it fits naturally into the wider picture in what app development costs in the UK in 2026.

If you want a second pair of eyes on a maps estimate, or you already have a bill that has grown faster than your user base, send us a project brief with your expected volumes. Most of the time the fix is a caching layer and a debounce rather than a change of provider.

Sources: Google Maps Platform pricing and billing overview, Mapbox pricing by product.