I Built a Revenue-Generating SaaS on GCP's Free Tier — Here's My Honest Receipts
Photo: Andre Carrotflower, CC BY-SA 4.0, via Wikimedia Commons
I went into this experiment expecting to write a takedown. "Free tier" in my mental model meant toy projects, portfolio sites, and the Node.js to-do app every bootcamp graduate has shipped. Then I spent a month running a real, revenue-generating SaaS — actual customers, actual invoices — on nothing but GCP's always-free offerings. I owe the free tier an apology.
But not a full apology. Because it bites in places, and knowing where is the difference between a viable product and a 3 AM pager alert about your egress bill.
The Stack That Costs Nothing
Here's what carried the entire product: Cloud Run (2 million requests/month free), Firestore in native mode with its generous daily allowance, Cloud Functions for background jobs, and Cloud Logging for the (very basic) observability story. Total infrastructure cost across the month: zero dollars and some cents I'm still auditing.
The trick isn't the services — it's the architecture. And that's where I borrowed shamelessly from Pune's frugal-engineering scene, where building for a billion users on a bootstrapped budget is simply how people learned to build.
Where the Free Tier Shines
Cloud Run is the star. Scale-to-zero means idle hours cost nothing, and cold starts on a simple containerized API were fast enough that no customer ever mentioned them. For a SaaS with spiky, modest traffic — which is most early SaaS — this is genuinely free money.
Firestore's free allowance covers a surprising amount. My app's read/write pattern was user-scoped and shallow, which is exactly the shape Firestore rewards. If your data model is relational and join-heavy, this paragraph does not apply to you.
Where It Bites
Egress is the silent killer. The free tier's network allowance is fine until one customer starts pulling reports. I caught it because I'd set a budget alert on day one — a habit I picked up from engineers who treat cloud spend like a leaky faucet, not a rounding error. Set the alert. Set it today.
No free support, and the docs assume context. When IAM permissions ate an afternoon, I was on my own. Budget your debugging time accordingly.
The ceiling is real, just farther away than you think. My app could scale to maybe a few thousand active users before free tier economics break. That's not a constraint — that's a milestone.
The Frugal Architecture Rules That Made It Work
- Cache aggressively, compute reluctantly. Every request you avoid is a request you don't pay for.
- Design the data model around the free tier's strengths. User-scoped documents, shallow queries, no fan-out monsters.
- Budget alerts on day one. Non-negotiable. Your future self sends thanks.
- Plan your exit ramp. Know which service you'll migrate to first when you outgrow free. Mine's Cloud SQL. Yours probably is too.
The Verdict
The free tier isn't a sandbox — it's a business model for the first chapter of a company, provided you architect with restraint instead of optimism. US founders default to over-provisioning because capital is cheap and fear of scale is expensive. Flip that. Build like the bill matters, because someday it will — and until then, enjoy invoicing customers from infrastructure that costs less than your coffee subscription.
