The Near-Zero-Cost Architecture: Scaling Web Tools on Static Edge CDNs

Every indie project inherits the same financial script without anyone writing it. Traffic arrives—good news—and with it server compute that scales per request, database reads that scale per session, egress billed by the gigabyte, log ingestion priced per line, and an observability stack whose invoice grows because the product is succeeding. The perversity is structural: you pay your cloud provider per unit of user-perceived value, so every improvement in traction degrades margins. Free tiers postpone the reckoning until the month the product finally works, then hand it a cliff.

There is an architecture that rewrites this script for a wide class of products—the tools, utilities, converters, editors, and content sites where computation can happen on the user’s device. Ship static code to an edge CDN, let visitor hardware do the work, keep no session state, store nothing about anyone, and the entire scaling story evaporates. This article lays out that model as practiced by Awesome Crate’s zero-upload architecture—the economics, the caching discipline that makes it fast, and, just as important, its honest limits. “Near-zero” is the correct phrase throughout: nothing here claims literally zero cost, and the difference matters.

The SaaS cost curve nobody budgets emotionally

Conventional wisdom treats infrastructure cost as a fixed tax plus a growth variable, but the components compound nastily:

Cost center	Scales with	Character as traffic grows
Server compute	Requests × CPU time	Linear or worse; autoscaling converts virality directly into invoices
Database	Rows read/written, connections	Superlinear once joins and indexes strain
Egress	Bytes delivered from origin	Per-gigabyte billing punishes success twice
Logs & telemetry	Events ingested	Grows with both users and your own instrumentation habits

Two dynamics make this curve emotionally brutal rather than merely expensive. First, the free-tier cliff: development happens comfortably inside generous allowances, so the true marginal cost of a user stays invisible until launch-scale traffic reveals it all at once. Second, coupling: because compute, storage, and egress are metered separately but consumed together, optimizing one usually surfaces another. A product that stores documents server-side pays compute to process them, storage to keep them, egress to return them, and logging to watch it happen—four meters running on one feature.

Inverting the model: ship code, not compute

The alternative architecture relocates the expensive half. Instead of servers executing logic per request, the build pipeline compiles the application into static assets—HTML shells, hashed JavaScript bundles, WebAssembly modules, fonts, images—and distributes them through a global edge network. When a user loads the tool, their browser downloads the program and their CPU, GPU, and memory execute it locally. Files they process stay in their RAM; results save back to their disk. The server never participates in any individual act of computation.

The economics flip accordingly:

1. Compute cost transfers to devices users already own. One million conversions cost the operator exactly what zero conversions cost—edge networks serve identical bytes whether ten people or a million load them, at rates negotiated by bandwidth contract rather than per-request metering.
2. No session state means no database. If the tool keeps nothing about a user between requests, there is no database to provision, scale, back up, or breach. State lives where it belongs—on the user’s machine, in IndexedDB or OPFS.
3. Scaling stops being an engineering topic. Capacity planning reduces to “the CDN handles it.” Incident response shrinks because there is no server process to hang, leak, or OOM-kill.

A concrete deployment inventory makes the shape tangible. A typical build emits an index.html shell, one hashed JavaScript bundle per route, a WebAssembly module with its glue code, fingerprinted font and image directories, and service-worker files—uploaded once per release to object storage behind the CDN. There is no process model, no restart story, no capacity tier to select. The entire production footprint is files at rest, replicated geographically, waiting to be downloaded.

This is the same inversion described conceptually in what local-first software means, viewed here through its financial consequences: client-side sovereignty is not only a privacy stance, it is an operating-budget stance.

Privacy is a cost reducer too

The conventional framing treats privacy as a compliance expense. In this architecture it runs the other direction: because nothing uploads, whole categories of obligation vanish before they arise.

Data-protection regimes attach duties to holding personal data—lawful-basis documentation, data-subject access and deletion machinery, retention schedules, breach notification readiness. An operator who never receives the data has almost none of that surface: there is nothing to disclose, nothing to delete on request, and—most consequentially—nothing to lose in a breach. The security posture collapses from “defend the vault” to “there is no vault.” Moderation queues, PII audits, and cross-border transfer analyses similarly dissolve when no user content transits your systems.

This is worth stating plainly because it inverts the usual pitch: the zero-upload model is often sold as ethics and experienced as overhead reduction. It is genuinely both, and the second half funds the first. Our transparency post on why the Journal needs ads and how to allow them covers how revenue works when the product itself stays free of data collection.

Caching like you mean it

Near-zero infrastructure only feels instant if assets arrive from as close to the user as possible and stay there. That requires deliberate cache policy, built on one principle: separate the immutable from the mutable.

Bundlers fingerprint content into filenames—app.a3f9c2.js. Once a filename encodes its own contents, that file can be cached forever without staleness risk:

/assets/*
  Cache-Control: public, max-age=31536000, immutable

/*
  Cache-Control: public, max-age=0, must-revalidate

Two rules carry the whole scheme. Hash-named assets get max-age=31536000, immutable, telling browsers and edge nodes alike that a year-long cache is safe and revalidation pointless. The HTML shell—the only file whose name never changes—gets must-revalidate so deployments propagate within a single request. Deploying becomes atomic in effect: new HTML references new hashes; old cached bundles serve old HTML harmlessly until evicted. No purge scripts, no stale-cache roulette.

A service worker extends the same discipline offline:

// install: cache the build manifest so revisits and offline both hit disk
self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open("shell-v1").then((cache) => cache.addAll(MANIFEST)));
});

Versioning the cache name (shell-v1) doubles as the eviction strategy—activation deletes predecessor caches, so stale bundles cannot accumulate indefinitely.

A tool that keeps working on airplanes is not a demo trick but the product itself for document editors built on WebAssembly; caching policy is what puts it within reach of every visit afterward. We covered that engine side in how WebAssembly enables offline PDF editing. Cache invalidation—the supposed hard problem of computer science—reduces here to naming discipline: never change what a name refers to, only which names exist.

The honest limits

An architecture article that lists only benefits is marketing. What actually remains on the bill, and where the model breaks:

• Real recurring costs persist. Domain registration, DNS, build minutes, form handling, and—once traffic is genuinely large—egress negotiated with the CDN. Revenue infrastructure such as ad networks adds its own integration surface. These are modest and flat-ish, which is the point, but “flat” is not “zero.”
• Dynamic needs reintroduce servers. The moment a product requires shared state across users—accounts with sync, comments, multiplayer—it has a backend again, with everything that implies. Client-side sync protocols can push the server down to a dumb relay (as discussed in the CRDT context), but even a dumb relay is a running thing someone pays for.
• Some computations exceed devices. Heavy AI inference beyond what WebGPU comfortably hosts, video transcoding at scale, and jobs needing specialized hardware remain server-shaped problems.
• Security patches ship on your cadence. With no server fleet to update centrally, users running cached copies of an older build keep it until their browser revalidates the HTML shell—usually hours, occasionally days. Critical client-side vulnerabilities demand the same disclosure discipline native apps practice, plus the quick redeploy that the immutable-cache scheme makes painless.
• Support burden does not vanish. Users with old browsers, blocked workers, or corrupted storage still need help. The code ships statically; the humans do not debug themselves.

Choose this architecture when the product’s core value is transformation of user-owned inputs on user-owned machines. Choose differently for realtime collaboration, centralized intelligence, or anything whose essence is shared state.

Questions people often ask

Are free tiers of static hosts sustainable long-term?

For this workload class, yes—static asset serving is nearly free for providers to deliver, which is why their free tiers are genuine rather than promotional. The prudent practice is keeping assets lean and knowing each provider’s fair-use terms, since sustainability comes precisely from products like these staying cheap to host.

Does going static create vendor lock-in?

Less than most infrastructure choices. Static files are the lowest common denominator of hosting: the output deploys unchanged to any competing edge provider, and migration is redeployment. Lock-in risk concentrates in proprietary edge functions—avoid weaving them into the critical path and portability stays trivial.

What about SEO on a fully static site?

Static rendering is, historically, the most crawler-friendly arrangement possible: complete HTML arrives on first request, no client-side hydration required. Content sites and tools built this way index cleanly, provided semantic markup and metadata ship in the shell. One nuance worth knowing: pages that render entirely client-side should still emit complete meta tags and structured data server-side or at build time, since crawlers execute JavaScript inconsistently.

Where does advertising revenue fit this model?

Comfortably, because ad networks monetize attention rather than data pipelines—the operator trades page views for revenue instead of trading user profiles. Contextual ad serving needs no behavioral history, which keeps the zero-collection posture intact while covering those remaining flat costs. That is precisely the arrangement documented in our ads transparency post.

The takeaway

The near-zero-cost architecture is client-side sovereignty expressed as an income statement. Move computation to the devices that already belong to users, keep nothing that would force a database into existence, fingerprint every asset so caches can trust files forever, and the infrastructure bill flattens from a growth function into a rounding error—domain, DNS, builds, done. It will not fit every product, and the honest list of exceptions is part of the design. But for tools whose value is computed locally anyway, the traditional SaaS cost curve was always an implementation detail, not a law of nature. Build on the edge, compute in the browser, and scale becomes someone else’s pricing page.