What 'Free' Actually Means Across a Multi-Service Google Stack

I want to be upfront about something before this post goes any further: I don't have a clean dollar figure to show you. I went looking for one -- I wanted to open the Google Cloud billing console, screenshot a $0.00 total, and call it proof. What I found instead was that "free" across a multi-service Google stack isn't one number at all. It's a pile of separate ceilings, each with its own reset clock, its own fine print, and in at least one case, a wall that had nothing to do with usage limits and everything to do with a policy I didn't know existed. This is the more honest version of that post -- what "free" actually meant, service by service, including the parts that cost me time instead of money.

The free tiers that behaved exactly like the docs said

Two services in this pipeline were boring in the best way -- I read the limit once, stayed under it, and never thought about it again.

• Blogger API v3 has no meaningful quota for a single-author blog. It's a legacy Google product that's still maintained, and nothing about posting, updating, or publishing through the API has a cost attached at this scale.
• dev.to's API is free for posting and reading, full stop, with no billing account involved at all -- refreshing, after spending so much time inside Google Cloud's console.

The free tier that has more than one number in it

Google Cloud Text-to-Speech looks like a single "free tier" on the pricing page, but it's actually several different ceilings stacked depending on which voice model you use -- Standard, WaveNet, and Neural2 voices are metered separately, and the Neural2 allowance is meaningfully smaller than the other two. I'd recommend checking the current numbers directly on Google's pricing page before you plan a project around them, since free-tier terms are exactly the kind of thing that gets revised without much fanfare -- but the shape of it, at least when I set this up, was: generous character allowances on the older voice models, a noticeably tighter one on the newest, most natural-sounding tier. If your project leans on the nicest-sounding voices specifically, that's the number to actually watch, not the headline "free tier" claim.

The one that wasn't a usage limit at all

The most expensive part of this build, in time if not in dollars, wasn't a quota. It was an organization policy -- iam.disableServiceAccountKeyCreation -- silently blocking me from generating a service account key on a project I owned outright, because my Google account happened to sit inside an org where that constraint defaults to on. Nothing about that shows up on a pricing page, because it isn't a pricing question. It's worth naming as its own category of "free tier cost": the setup friction that has nothing to do with usage and everything to do with defaults you didn't choose. I ended up switching to an OAuth-based auth flow instead of fighting the policy, which turned out to be less work anyway.

The one I still can't give you a confident number for

Google Cloud Storage's free tier -- relevant if you're hosting generated images or audio anywhere other than inline in your content -- is the one I'm least willing to state a specific figure for here. The free storage and egress allowances exist, but they're also the kind of number Google has adjusted before, and I haven't independently re-verified the current terms against my own account at the time of writing. If a project of yours actually depends on staying under that ceiling, treat whatever number you read anywhere, including this post, as a starting point to confirm on Google's own current pricing documentation -- not a fact to build on unchecked.

What actually forced a decision, versus what didn't

Looking back at every point where I had to stop and make a call, almost none of them were "I'm about to exceed a quota." They were closer to: an org policy blocking a key, a billing address that Google's system didn't recognize for a newly-split Korean administrative district, a DNS lookup failing because a machine hadn't finished waking from sleep. The free tiers themselves, once I understood their actual shape instead of the one-line pricing-page summary, were generous enough that usage limits never once forced a redesign. The friction was almost entirely operational -- verifying an address, understanding a policy, debugging a race condition -- not financial.

If you're planning something similar

The practical version of this post, if you don't want to read the rest of it: budget your setup time around policy and identity friction, not around character counts or API call limits. The free tiers on the usage side are more forgiving than they look. The parts that will actually eat an afternoon are the ones that don't show up on a pricing page at all.