I Nearly Got a £500 Google Maps API Bill: What AI Builders Should Check

My normal Google Maps Platform bill was around $40 a month.

Then one month it jumped to roughly £500.

That is not the kind of notification you want to see when you are running a real platform, especially when the product depends on location features and usage-based APIs.

This was not a story about Google APIs being bad. I still use Google Maps Platform. The issue was that a working feature had been treated as finished before the cost, security and abuse controls were properly tightened.

That is the lesson for AI builders, vibe coders and founders building real web applications with AI support.

A feature is not finished just because it works in the browser.

If it uses a paid API, you also need to check:

• Who can use the key.
• Which APIs the key can call.
• Where the key is allowed to run.
• What happens if bots hit the page.
• Whether your implementation makes unnecessary calls.
• Whether quotas and alerts are in place.
• Whether you can spot unusual usage quickly.

I learned that lesson the uncomfortable way.

The app used Google Maps Platform for real product features

The platform was a UK coach and minibus directory.

It used Google Maps Platform in several places, including:

• Places API for address autocomplete.
• Maps JavaScript API for embedded maps.
• Geocoding API for distance calculations and location lookups.

These were not experimental extras. They supported real user journeys.

Customers needed to search by location. Operators needed to appear in relevant areas. The platform needed maps, addresses, distances and location logic to behave sensibly.

That meant Google Maps Platform was part of the product, not just a decorative map on a contact page.

For months, the cost was manageable. Around $40 a month felt normal for the level of usage.

Then the bill jumped.

The investigation showed unusual usage

After the bill spike, I started digging into the Google Cloud usage data.

I also worked through the issue with ChatGPT to make sense of the logs, the API usage and the possible causes. Eventually I raised the issue with Google support.

The usage pattern did not look like normal UK customer activity.

The logs showed unusual traffic attributed to my staging domain. That detail mattered, but it also needed careful interpretation.

I could not definitively prove whether the staging app itself was being loaded in the normal way, or whether the exposed key and allowed referrer pattern were being abused. What was clear was that the key configuration had left too much room for unwanted usage.

After a lengthy appeal process, the charge was refunded.

I was grateful for that outcome.

But the bigger lesson was obvious: this should have been prevented earlier.

The platform had working Google Maps features, but the surrounding controls were not strong enough.

Mistake 1: the browser API key was too permissive

The first mistake was an overly permissive browser API key.

Browser keys are awkward because they are exposed to the client by nature. If a map or autocomplete feature runs in the browser, the key is visible in the frontend. That does not automatically mean the setup is unsafe, but it does mean restrictions matter.

A browser key should not be treated like a private secret.

It should be treated like a public key that needs tight limits.

Before the incident, my setup was too loose. The key could be used in ways it should not have been able to be used.

Afterwards, I changed the setup properly:

• Rotated credentials.
• Separated browser and server API keys.
• Restricted browser keys to the correct production and staging domains.
• Restricted server keys by server IP where appropriate.
• Limited each key to only the APIs it needed.
• Added quotas.
• Added budget alerts.
• Added extra bot protection.

The principle was simple: each key should have the smallest practical permission set.

A browser key used for Maps JavaScript and Places autocomplete should not be able to call unrelated APIs. A server-side key should not be usable from random websites. A staging environment should not be treated casually just because it is not the public production site.

Google’s own documentation on API security best practices and quota and cost controls is worth reading before you ship anything that depends on Maps Platform billing.

Do not wait until the bill looks strange.

Mistake 2: one page was wasting Places API quota

The second issue was not the cause of the full bill by itself, but it was still important.

One page was not using the normal Google Autocomplete widget.

Instead, it manually called parts of the Places flow, including AutocompleteService, getPlacePredictions and PlacesService.getDetails.

That kind of implementation can be valid, but it needs care.

In this case, the page could perform more prediction and detail lookups than necessary before settling on a destination. It worked from a user point of view, but it was wasteful from an API usage point of view.

That matters because paid API features are not only judged by whether the interface behaves correctly.

They also need to be checked for cost behaviour.

If a user types five characters into a field, how many API calls happen?

If they change their mind, what happens?

If a destination has already been resolved, does the page stop looking it up?

If bots hit the page, can calls multiply?

If the component re-renders, does it trigger more requests than expected?

After reviewing the page, we refactored it so it stopped making unnecessary lookups once a location had been resolved.

Again, this was not the whole billing incident.

But it was a real inefficiency, and it should have been tightened earlier.

Working does not always mean finished

This is one of the biggest lessons for people building with AI.

AI can help you get a feature working quickly.

That is useful.

You can ask a conversational assistant to explain a Maps API error. You can ask for help wiring address autocomplete into a form. You can ask for a geocoding function, a distance calculation or a map component. You can use AI-assisted development environments to build the first version of a page faster than you might have done manually.

But a working feature is not necessarily a finished feature.

Especially when money is attached to usage.

A paid API feature needs extra checks:

• Is the key restricted?
• Is it the right kind of key?
• Is it being used on the client or server?
• Is it limited to the APIs it needs?
• Are there quotas?
• Are there budget alerts?
• Are requests being debounced?
• Are duplicate calls avoided?
• Is the feature protected from obvious bot traffic?
• Is staging locked down?
• Is usage being monitored after release?

AI can help you build the feature.

But human judgement still has to ask whether the feature is safe enough to run.

That is not anti-AI. It is the reality of building real software.

AI-assisted code can make paid API features work before they are cost-aware

When you are building with AI, it is easy to stop once the feature appears to work.

The autocomplete suggests addresses. The map loads. The distance is calculated. The page looks fine.

So you move on.

But AI-assisted code can often optimise for visible success first.

It may not automatically design for cost control, abuse prevention, rate limits, caching, debouncing or billing alerts unless you ask for those things and inspect the result.

That is not a criticism of AI. It is a reminder that the builder has to define what “done” means.

For a paid API feature, “done” is not:

The feature works once on my machine.

A better definition is:

The feature works, uses the right key in the right place, only calls the APIs it needs, avoids unnecessary requests, has sensible quotas and alerts, and has been tested for obvious failure and abuse cases.

That is a higher standard, but it is a necessary one.

A checklist for using paid APIs safely

This is not legal, security or billing advice. It is a practical checklist based on a real lesson I wish I had tightened earlier.

Before treating a paid API feature as finished, check the following.

1. Separate browser and server keys

Do not use one key for everything if the API provider allows a better structure.

Browser keys and server keys have different risk profiles.

A browser key is visible to users because it runs in frontend code. A server key should stay on the server and should not be exposed in the browser.

Separate keys make it easier to restrict and monitor usage properly.

2. Restrict keys by application

For browser keys, restrict usage to the domains that should be allowed.

That usually means your production domain and, if needed, specific staging domains.

For server keys, use server-side restrictions such as IP restrictions where appropriate and supported.

The goal is to stop a key being useful outside the places it is meant to run.

3. Restrict keys by API

A key should only be able to call the APIs it actually needs.

If a key is only for Maps JavaScript and Places, do not leave it open to unrelated APIs.

This reduces the damage if something is exposed or misused.

4. Use quotas and alerts

Quotas help limit usage. Budget alerts help you notice spend before it becomes painful.

A budget alert is not the same as a hard stop for every kind of usage, so do not treat it as your only control. But alerts are still useful because they give you an earlier warning when something changes.

Review the provider’s own quota, billing and alert tools before going live.

5. Watch staging environments

Staging is easy to neglect.

It should not be public, permissive and forgotten.

If staging uses real API keys, it needs controls. If it does not need real paid API access, consider using safer test settings, separate keys or tighter restrictions.

Staging should help you test safely, not become a quiet source of risk.

6. Check call efficiency

A feature can work and still make too many calls.

Look at the actual request pattern.

For autocomplete, ask whether predictions are being requested too often. Check whether detail lookups happen only when needed. Watch for repeated calls after a value has already been selected.

Small inefficiencies can become expensive when traffic increases or bots get involved.

7. Add bot protection where it matters

If a public page can trigger paid API calls, think about bot traffic.

That might mean rate limiting, CAPTCHA or Turnstile-style checks in the right places, server-side validation, request throttling, or simply avoiding unnecessary paid calls until there is clearer user intent.

The right solution depends on the feature, but ignoring bots is not a strategy.

8. Monitor after release

Do not assume the first deployment tells you everything.

Check usage after the feature goes live.

Look for unusual countries, referrers, spikes, API methods or times of day. Compare usage with what you expect from real users.

If your product serves a UK customer base and the logs show a pattern that does not match that, investigate.

A prompt to ask AI before shipping a paid API feature

Here is a prompt I would use before treating a paid API integration as finished.

I am using a paid API in this web app. Please review this feature from a cost, security and abuse-prevention point of view. Do not just check whether it works. Help me identify:

• Which calls are made from the browser.
• Which calls are made from the server.
• Which API keys are exposed to the client.
• Which domains or IPs should be allowed.
• Which APIs each key should be restricted to.
• Whether the feature could make unnecessary repeated calls.
• Whether debouncing, caching or stopping conditions are needed.
• What quotas, budget alerts or usage monitoring I should set up.
• What bot traffic could trigger paid usage.
• How I should test the feature before shipping.

That prompt will not replace a proper review.

But it will force better questions.

It also changes the conversation from:

Does this feature work?

To:

Is this feature safe, controlled and cost-aware enough to run?

That is the mindset AI builders need.

The VCA lesson: build, inspect, test, protect and improve

This experience reinforced something we teach inside Vibe Code Academy.

AI-assisted building is not just prompting.

It is workflow.

Build the feature.

Inspect what changed.

Test how it behaves.

Protect the risky parts.

Improve the implementation.

When you are working with paid APIs, “protect” becomes especially important.

That includes API key restrictions, environment variables, quotas, budget alerts, bot protection, staging discipline and request efficiency.

You do not need to become a cloud security expert before building anything. But you do need to understand enough to avoid leaving expensive doors open.

That is part of building real software.

Final lesson for vibe coders and AI builders

The lesson from my £500 Google Maps API scare was not that Google Maps Platform is bad.

The lesson was that a working API feature was not finished.

It needed tighter key restrictions. It needed better separation between browser and server usage. It needed quotas and budget alerts. It needed more attention to staging. It needed bot protection. It needed a closer look at request efficiency.

AI helped me investigate and fix the problem, but it did not remove my responsibility as the builder.

That is the wider point.

If you are building with AI, do not only ask:

Can I make this work?

Also ask:

Can I run this safely?

Especially when a paid API is involved.

A real product is not just a set of working screens. It is a system with costs, limits, users, errors and edge cases.

That is why the VCA workflow is not only build, build, build.

It is build, inspect, test, protect and improve.

If you want to understand the more deliberate human-in-the-loop approach behind that, read our guide to AI-assisted software engineering.

If you are earlier in your journey, learn coding with AI is a useful place to start before the expensive surprises.