We Were Paying $8,000/Month for Google Maps. Then We Stopped.

Here’s what actually happened when we ripped out Google Maps from a production delivery platform and replaced it with an open-source routing engine.

The bill nobody talked about

When you’re building a delivery platform, Google Maps feels like the obvious choice. It’s reliable, accurate, and it works on day one. So that’s what we used.

The platform was Oman’s largest delivery ecosystem — multiple apps, hundreds of active drivers, thousands of orders daily. Routes needed to be calculated in real time. ETAs had to be accurate. Distance matrices ran constantly in the background to match drivers to orders.

None of that is cheap on Google Maps APIs.

By the time the platform hit full operational scale, the monthly Google Maps bill had crossed $8,000. Not a one-time spike. Every. Single. Month.

Route calculations, distance matrix calls, geocoding, map tile rendering — it all adds up faster than you expect, especially when you’re running a platform where every order triggers multiple API calls across multiple services.

At some point, someone asked the obvious question: what are we actually paying for here?

What Google Maps gives you that OSRM doesn’t

I want to be honest about this, because most “ditch Google Maps” posts skip it.

Google Maps gives you:

• Global map data maintained by thousands of people
• Traffic-aware routing (real-time congestion data)
• Autocomplete address search with fuzzy matching
• A brand users recognize and trust

OSRM gives you none of those things out of the box.

OSRM (Open Source Routing Machine) is a routing engine. It takes OpenStreetMap data and lets you run extremely fast route calculations on your own infrastructure. That’s it. No traffic data. No autocomplete. No brand recognition.

So the first question we had to answer: does this platform actually need what Google gives you, or does it just need fast, accurate routing?

For a delivery platform operating in one country, with drivers following known road networks, without turn-by-turn navigation visible to end users — the answer was mostly the latter.

What we replaced

We didn’t rip everything out at once. We mapped every Google Maps API call in the codebase and categorized them:

Route calculation / directions — used when a driver is assigned an order, to calculate the optimal route. OSRM handles this natively and extremely fast. Replaced.

Distance matrix — used constantly for the dispatcher logic. Given N drivers and M orders, calculate which driver is closest to which order. This was the biggest API cost by far, because it runs on every new order and every driver status update. OSRM’s table service handles this. Replaced.

Geocoding — converting addresses to coordinates. This one is harder. OSRM doesn’t geocode. We evaluated Nominatim (open-source geocoder using OpenStreetMap data) and it worked well enough for Oman, where addresses follow predictable patterns. Replaced with Nominatim.

Map tiles / display — the visual map in the admin dashboard and driver apps. We switched to OpenStreetMap tiles served via a tile server. Not as polished as Google Maps visually, but functionally fine for a logistics dashboard. Replaced.

The setup

OSRM needs OSM data for the region you’re routing in. For Oman, we grabbed the extract from Geofabrik, ran it through OSRM’s preprocessing pipeline, and ended up with a routing graph we could query.

The preprocessing took a while. The queries are instant — OSRM is genuinely fast, faster than hitting Google’s API over the network.

We containerized everything with Docker and deployed it on AWS Fargate. The OSRM service, the Nominatim geocoder, and the tile server all running as Fargate tasks, behind an internal load balancer. No servers to manage, no capacity planning — Fargate just runs the containers.

We also added auto scaling. The distance matrix service in particular gets hammered during peak order hours — every new order triggers multiple routing calculations simultaneously. With Fargate auto scaling, the OSRM tasks scale out under load and back down when it’s quiet. We’re not paying for idle capacity at 3am.

The distance matrix calls that were previously going to Google now hit our own OSRM instance. Response times were better than Google in most cases, because we’re not crossing the internet.

One thing to plan for: OSM data gets stale. New roads get built, intersections change. We solved this properly — a daily automated job pulls fresh OSM data for Oman from Geofabrik, rebuilds the OSRM routing graph, and redeploys the Fargate image. The update happens overnight with zero downtime. Our routing data is never more than 24 hours old.

What the bill looks like now

The Google Maps monthly cost dropped to roughly $400.

That’s not zero. We kept Google Maps for one specific use case: the customer-facing address search in the ordering app. Nominatim’s autocomplete isn’t good enough for the consumer experience there — users expect fuzzy matching and forgiving input handling. Google Maps is better at that, and it’s worth paying for.

Everything else — routing, distance matrix, geocoding in the backend, map display — runs on our own infrastructure.

Fargate costs vary with load, but averages around $90/month across all services. Tile server hosting adds another $30. So we went from $8,000/month to roughly $520/month total for all mapping infrastructure.

What I’d do differently

The preprocessing pipeline documentation is rough. Budget more time than you think you need for the initial OSRM setup, especially if you’re not already familiar with OSM data formats.

Nominatim is good but not Google-good. Be honest about which parts of your product actually need Google-quality address search and which don’t.

Map tiles look different from Google Maps. If your users are used to Google’s visual style, there will be feedback. Plan for it.

One thing I’d set up earlier is the auto scaling policies. We tuned them reactively after seeing real traffic patterns — it would have been smarter to instrument the load first, then configure scaling thresholds based on actual data.

Should you do this?

If your mapping costs are under $500/month and your team is small — probably not worth the operational complexity of running your own routing infrastructure.

If you’re running a platform at scale in a specific geographic region, with predictable routing needs, and you have the engineering capacity to maintain the stack — it’s worth seriously evaluating.

The $8,000/month was a problem that had an engineering solution. We just took a while to look for it.

I’m a Technical Lead building production SaaS platforms. I write about the things that go wrong, the tradeoffs that don’t have obvious answers, and the decisions you don’t read about in documentation.

Writing at medium.com/@iamarshrx. Need architecture help? Message me on LinkedIn.