Free-Tier Infrastructure Mastery (Eleven Sprints, $0 Spent, Real Production Traffic)

The problem

Every startup hits the same wall: you need infrastructure to build a product, but you need a product to justify the infrastructure bill. The traditional answer was $3,000–$5,000 per month in cloud services before a single customer arrived. That answer is now wrong by an order of magnitude.

Cloudflare Workers handle 100,000 requests per day on the free tier with 10ms of CPU time per request — enough for ~2,000–5,000 daily-active users. Supabase ships 500 MB of PostgreSQL with row-level security, 50,000 monthly active users on the auth side, and 1 GB of file storage. Google Cloud throws in $300 of credit plus always-free quotas. Stacked correctly, these three providers run a production system for $0/month — not for the first weekend, not for an MVP demo, but through real traffic past initial product-market fit.

The catch: stacking them correctly means treating the free-tier limits as production targets, not development conveniences. The 10ms CPU budget shapes handler design. The 100K requests-per-day cap forces aggressive caching. The 500 MB PostgreSQL limit shapes schema toward narrow indexed tables. The architecture is not “compromise” infrastructure — it’s the same infrastructure Pragma.Vision ran through eleven development sprints without spending a cent.

What most people get wrong

Mistake one: assuming free tiers are for prototypes only. Most teams use free tiers for the first weekend and assume they’ll upgrade before launch. That mindset produces architectures that don’t survive the free-tier transition — they assume always-on origin servers, batch poorly, hammer the database on every page view when KV would do the job. The system can’t run cheaply because it was never designed to. The actual constraint of free tiers is what makes the architecture better: forced caching, forced batching, forced indexing.

The book inverts the framing. Cloudflare Workers is not “limited compute” — it’s edge compute distributed across 300+ data centers with sub-50ms cold starts. The 10ms CPU budget isn’t a cap, it’s a discipline: most API handlers complete in well under 5ms of CPU time because the SDK’s await keyword counts wall-clock time, not CPU time. A handler that waits 200ms for a Supabase query uses microseconds of CPU. The constraint forces handlers to do real work in the handler and let the database do real work in the database.

Mistake two: treating R2’s zero-egress pricing as a minor line item. R2 charges $0 for data transferred out — forever. AWS S3 charges $0.09 per GB. For a platform serving images, agent packages, or downloadable assets, that single difference eliminates the most unpredictable item on a typical cloud bill. Most cloud-cost templates have an “egress” line that grows with traffic; that line is $0 on R2 and stays $0 at any scale. The structural impact on multi-year financial modeling exceeds what most founders factor in when they pick a provider.

The book is built around the assumption that you do not pay for egress, you do not pay for bandwidth, and you do not pay for compute below a real traffic threshold. That changes which architectures are tenable at solo-founder scale.

A working approach

The three-pillar stack with the limits that actually shape architectural decisions:

Pillar	Resource	Free Tier Limit	What it shapes
Cloudflare Workers	Requests/day	100,000	API call discipline
	CPU time	10ms per request	Handler design
	Subrequests	50 per request	Downstream fan-out
Workers KV	Reads/day	100,000	Cache strategy
	Writes/day	1,000	Mutation pattern
D1	Rows read/day	5,000,000	Edge-local queries
	Rows written/day	100,000	Edge persistence
R2	Storage	10 GB	Asset budget
	Egress	Unlimited	Eliminates the bandwidth line
Supabase	DB storage	500 MB	Schema design
	Auth MAU	50,000	User account scale
	Edge functions	500,000/mo	Server-side logic
Google Cloud	Credit	$300 (one-time)	A2A bridge, overflow
	Always-free	2M Cloud Function invocations/mo	Steady-state compute

The Wrangler configuration the book uses as a starting point — annotated for the bindings that make the architecture work:

name = "my-api"
main = "src/index.ts"
compatibility_date = "2025-12-01"
compatibility_flags = ["nodejs_compat"]

# KV Namespace bindings
[[kv_namespaces]]
binding = "CACHE"
id = "abc123"

[[kv_namespaces]]
binding = "SESSIONS"
id = "def456"

# D1 Database binding
[[d1_databases]]
binding = "DB"
database_name = "my-app-db"
database_id = "ghi789"

# R2 Bucket binding
[[r2_buckets]]
binding = "ASSETS"
bucket_name = "my-app-assets"

# Cron triggers (5 max on free tier)
[triggers]
crons = [
  "0 */6 * * *",   # Every 6 hours: cache refresh
  "0 0 * * *",     # Daily: cleanup expired sessions
  "0 0 * * 1",     # Weekly: usage report
]

CPU-vs-wall-clock-time mechanics are what make 10ms-per-request feasible:

export default {
  async fetch(request: Request, env: Env) {
    // This JSON parse uses ~0.1ms CPU time
    const body = await request.json();

    // This KV read takes ~50ms wall-clock, but ~0ms CPU
    const cached = await env.MY_KV.get(body.key);

    // This computation uses ~2ms CPU time
    const result = processData(cached);

    // Total CPU: ~2.1ms (well within 10ms)
    // Total wall-clock: ~55ms (irrelevant to limit)
    return Response.json(result);
  }
};

The six architecture patterns chapter 6 walks through:

1. Edge-first with database fallback — KV-first read, Supabase-fallback on miss, write-through on update.
2. Tiered storage strategy — hot data in KV, warm data in D1, cold data in Supabase, archival in R2.
3. Split-brain architecture — separate Workers for read-heavy and write-heavy paths so caching can be aggressive on the read side.
4. Request batching — single /api/dashboard endpoint instead of five separate calls.
5. Intelligent TTL management — different cache TTLs for product catalog (hours) vs user state (seconds).
6. Supabase keep-alive circuit — a tiny cron that keeps the free-tier database active to avoid the inactivity pause.

Each pattern has a concrete code example in the book. Together they let the system handle real traffic without crossing any of the free-tier thresholds.

Where this scales

The article above is the limit-and-pattern overview. The full book extends in four directions:

• Per-resource deep dives — Cloudflare Workers, KV, D1, R2, Supabase, Google Cloud each get their own chapter with the exact limits, the configuration patterns, and the failure modes when a limit is hit.
• Monitoring on free tiers — the daily-usage-report Worker, the capacity-projection model, and the alert channels (Discord webhook, email-via-Workers) that cost $0/month.
• The upgrade decision framework — three upgrade triggers, the upgrade priority matrix, the upgrade decision checklist, and the year-one cost projection for each scaling band (1K, 10K, 100K DAU).
• The migration safety net — what to do when a single resource needs upgrading, how to migrate it without taking the rest of the stack down, and the long-term architecture for planning beyond the free tiers.

The bonus configuration files are the same wrangler.toml and supabase-config.toml referenced in the book — drop them into a project to start from a known-good baseline.

Included with the book

• supabase-config.toml — production-ready Supabase configuration with RLS defaults, auth settings, and the connection pool tuning that survives 500 MB free-tier limits.
• wrangler-template.toml — full Wrangler config with KV, D1, R2, cron triggers, and the bindings the book references. Replace the namespace IDs and deploy.

Get the full picture

Readers of this also chose

Questions readers ask

How long can I actually stay on free tiers?

Roughly: Workers covers 2,000–5,000 DAU depending on calls per session. Supabase auth covers 50,000 MAUs. R2 stays free up to 10 GB of storage with unlimited egress. The book includes upgrade triggers per resource so you know which one breaks first for your traffic shape — usually Supabase storage if your data is dense, or Workers requests if your client makes too many calls per session.

Does this work for non-AI products?

Yes. The architecture patterns and resource limits are generic. The book uses AI commerce as the example domain because that's what the Pragma.Vision stack runs, but every pattern applies to any product that needs edge compute, relational data, and object storage.

What about Google Cloud after the $300 credit runs out?

Chapter 5 covers the always-free Google Cloud quotas (2 million Cloud Function invocations per month) and the Google for Startups program for additional credit. For most products the $300 credit lasts well past the point where revenue can cover the marginal usage.

Will my Supabase project pause for inactivity?

Yes — the free tier pauses after seven days of no activity. Chapter 6 includes the "Supabase keep-alive circuit" pattern: a tiny cron Worker that pings the database periodically to keep it active. Cost on free tier: $0.

What's the refund policy?

Lemon Squeezy's standard refund window applies. If the architecture doesn't match your stack, the refund link is in the receipt email.