The free app stack

The teaching point: start static and add dynamic pieces only where a static page physically cannot do the job. Every server-rendered piece is a cost and a responsibility you accept on purpose. Most projects overestimate how much dynamism they need.

Some of the best data on the internet is free with no key at all: weather forecasts, earthquake feeds, space-weather readings, public event data. For these, the visitor's browser can call the API directly — nothing secret is involved.

When an API does require a key, the key never reaches the browser. It lives in an environment variable, and a small serverless function attaches it to the request server-side. The pattern, in simplified form:

// Serverless function: runs on the platform's servers, never in the browser
export default async function handler(req, res) {
  // The key lives in an env var set in the deploy dashboard. The browser never sees it.
  const key = process.env.DATA_API_KEY;
  // Attach the key however this API expects it, then forward the reply.
  const upstream = await fetch(buildKeyedUrl(req.query, key));
  res.status(200).json(await upstream.json());
}
// The browser only ever calls YOUR endpoint:
fetch('/api/data')

Simplified illustration of the pattern. Your real function fills in that API's URL and key scheme. The most common beginner mistake is pasting a key into frontend JavaScript — which ships it to every visitor.

• Cache responses for a few minutes. Free public APIs are shared resources with rate limits and fair-use policies. A short cache means you almost never touch the limit.
• Rate-limit your own endpoint so one enthusiastic visitor cannot burn your upstream quota.
• Disclose what you call. If your page fetches live data, say where it comes from — it builds trust and it is honest about freshness.

Free tiers are not charity. They are customer acquisition: the platform pays for your compute today because some fraction of free users grow into paid teams tomorrow. Understanding that makes the limits make sense:

• The limits are the product. Bandwidth caps, build minutes, and function timeouts are where the free tier ends and the paid pitch begins. They are published on purpose.
• Free owes you nothing. No SLA, no support queue, no promise the terms stay put. Never run something business-critical — or someone else's business — on a tier that guarantees nothing.
• Terms change. A generous free tier today can tighten tomorrow. The guides that quote exact limits go stale; the guides that teach you where the limits are published stay useful.

None of this is a reason to avoid free tiers. It is the reason to treat them as the on-ramp, not the whole road — and to know exactly where the road starts charging.

Cost growth follows a predictable ladder. Each rung is one new need, not a rewrite:

• $0 — static site on a subdomain. Pages, browser tools, and no-key APIs. This is where everything starts.
• One yearly line item — a custom domain. The name you actually want. Still $0 for hosting.
• First paid step — a published limit bites. Bandwidth or build minutes run out mid-month, or serverless functions time out because the work genuinely needs minutes instead of seconds. The dashboard tells you which cap hit. That is the tier telling you the project is real.
• Next — persistent data and background work. A real database with private user data, long-running jobs, or heavy server computation. That is a paid-tier or dedicated-service job, and that is fine.
• Finally — guarantees and teams. SLAs, support queues, collaboration features, access controls. The moment someone else's business depends on your uptime, pay for the tier that promises it.

The rule never changes: upgrade when a published limit actually bites, not before. The $0 pattern is not a phase you are supposed to feel guilty about outgrowing — it is the on-ramp, and the dashboard tells you when you have arrived at the next one.