Day Zero Kit

Should you switch on Google Places?

Not as the backbone of your venue pages, and not before a daily quota, budget alerts and an exit path are written down. The real choice is whether every search and venue view should call a pay-per-call API, and that is cheapest to settle before launch. The decision is yours.

What happened when we did exactly this

The guide's Product B, a store discovery app, used Places for search, details, a location picker and photos (measured, Aug–Sep 2026):

• August: Places cost about $31, which was about 72% of the project's $42 Google bill. That split into 3,786 photo calls (about $19) and 1,608 Enterprise detail calls (about $12). The estimate had been $1 a month.
• Thumbnails: each list thumbnail was a separate paid photo request. A results page with 20 images cost about $0.13 after the free tier.
• Field mask: one broad field mask billed every call at the Enterprise rate. Five one-off maintenance scripts made about 1,500 of those calls in three days.
• September: caching and narrower masks still left the bill at about $13. About a quarter of night traffic was bots, and one scraper sent about 25,700 requests a day. Google was removed and the bill went to $0, but ratings and opening hours were lost.

Options

A cost assumption to confirm

Assume 1,000 venue page views a day, each with one Enterprise details call (for rating and hours) and one photo. That is about $0.027 a view, so about $27 a day and about $780 a month after the free tier, before any search costs. On a bad day, one scraper like ours hitting 25,700 venue pages costs about $690 in a day. Is 1,000 views a day right for you?

The guide's default

Look at the alternatives before turning on the key. Build the catalog from data you're allowed to store (an open-data import plus your own uploads), and use Google only where that data has gaps. Pay-per-view billing multiplies every bot, server-side render and retry. And if a field only Google provides, like ratings, becomes part of what your product promises, leaving Google later gets expensive.

This default doesn't fully fit you, because open data has no ratings or hours. If you need them at launch, the guide's fallback is to use Google only for that gap:

1. Field masks: request Enterprise fields only on the venue page. Lists and pickers use ID-only or Essentials fields, with a separate field mask for each caller. Lists never show Google thumbnails.
2. Keys: use a separate key per platform. Restrict the server key by IP, the web key by referrer, and the iOS/Android keys by bundle ID or package name and signature. Allow only the APIs you use.
3. Daily quota: set a hard limit equal to what you'd accept losing in a day divided by the price per call ($2 ÷ $0.02 ≈ 100 calls). When it's hit, the app falls back to your own data.
4. Budget alerts: set them at 50%, 80% and 100%; they warn you but don't stop spending. In the first month, read the bill weekly, broken down by SKU.
5. Exit and privacy: record where each venue record came from, so Google's rows can be deleted in one step. Users' search text and location go to Google, so name Google in your privacy notice.

How solid this is: the costs were measured, and the replacement (OpenStreetMap plus our own data) runs in production. Foursquare OS Places and Overture are suggestions we haven't tried.

Checked today (12 Oct 2026)

• Every price and free-tier figure above matches Google's pricing page.
• place_id can be stored with no time limit. Photo names can't be cached. Photos and reviews must show attribution.
• Google Cloud's spend-cap budgets cover only the Gemini API, Agent Platform (Vertex AI), Cloud Run and Cloud Run functions, not Maps. So the daily quota is the only thing that actually stops spending.
• Not checked today: the 30-day limit on storing coordinates and the rule against showing Places data on a non-Google map, because Google's terms page didn't load. Foursquare, Overture and OpenStreetMap terms weren't checked either. These come from the guide's October 2026 snapshot.

Next steps

1. Confirm the daily page-view figure and the most you'd accept losing in a day.
2. Decide whether you need ratings and hours at launch, or whether they can come later from your own data.
3. Import one city from Foursquare OS Places or Overture and measure how many of your venues it covers.
4. Enabling billing, the API, the keys and the quota is your job; I won't switch anything on.

Decision record (docs/DECISIONS.md)

## K-<n> Venue data: Google Places or own catalog
Date: 2026-10-12. Status: in force.
Decided by: product owner.
Context: venue pages need photos, ratings and hours before launch.
Decision: <your choice>
Options: <why the others were not chosen>
Cost: ~$... a day, ~$... a month, worst day ~$...; cap and alarm: daily quota ... calls, budget alerts 50/80/100%
Result: <which screens use which source>
Revisit: <date or condition>
Link: Google Maps Platform pricing page; guide "Expensive external APIs"