I shipped 122 web tools without a backend

A year ago I deleted my server bill.

Not because I was broke. Because I realized that for the kind of tools I was building — file converters, formatters, calculators, generators — the server was the worst part of the architecture. It cost money, it leaked user data, it added latency, and it was the single biggest reason competitors in the space charge $9.99/month for a feature that could run in 3KB of JavaScript.

So I deleted it. Then I built 122 browser-based tools on top of that decision. Here's what actually worked, what didn't, and why I think every dev should be re-evaluating the "we'll just spin up a Lambda" reflex.

The thesis

Every file you upload to a SaaS converter is:

1. Sent over the network (slow)
2. Processed on someone's server (expensive)
3. Stored, even briefly (privacy risk)
4. Returned to you (slow again)

For ~80% of common tools, none of those steps need to happen. The browser in 2026 can do it. Not "kind of," not "with limitations" — actually do it, often faster than the round-trip to a server.

The mental shift: stop thinking of the browser as a thin client.

What worked surprisingly well

WebAssembly for "real" file processing

Every PDF tool I shipped runs in the browser via WASM. PDF compression, merging, splitting, conversion — all of it. The wins:

// Pseudocode for the pattern that replaced our backend
const file = await input.files[0].arrayBuffer();
const result = await wasmModule.compress(file, { quality: 0.7 });
download(result, 'compressed.pdf');

That's it. No upload. No queue. No "your file is being processed." A 50MB PDF compresses in ~2 seconds on a mid-range laptop, faster than uploading it to a server would take.

The same pattern works for image compression, video trimming (with FFmpeg.wasm), audio conversion, and even some surprising things like ZIP creation and EPUB generation.

If you're still routing files through a server for compression or format conversion, you are paying real money to deliver a worse experience.

Pure-JS for the boring 80%

Most "tools" don't need WASM. Most don't even need a framework. A JSON formatter, a regex tester, a character counter, a text case converter — these are 50–200 lines of plain JavaScript. The tool is the value. The framework is overhead.

I tried Vue. I tried plain HTML. I ended up on Next.js for SEO reasons (more on that below), but each tool's actual logic is a single function. Don't over-engineer.

Web Workers for anything >200ms

The single biggest UX upgrade across the whole site came from one rule: if a computation takes more than 200ms, it goes in a worker. Otherwise the page freezes during processing and people think the tool is broken.

const worker = new Worker(new URL('./hash.worker.js', import.meta.url));
worker.postMessage({ file, algorithm: 'sha256' });
worker.onmessage = (e) => updateUI(e.data);

Hashing a 1GB file on the main thread → frozen tab → user closes it. Hashing the same file in a worker with progress events → smooth experience, user trusts the tool. Same code, ten times the perceived quality.

What didn't work

"Just ship 122 tools and the SEO will come"

This was wrong. I shipped them, they got indexed (264 pages eventually), and Google parked the entire site at average position 72 for months. Indexed ≠ ranking.

The fix wasn't more tools. It was fewer, better-linked, better-content tool pages. Each tool now has:

• A unique H1 with the actual keyword
• A "How it works" section explaining the in-browser processing
• An FAQ targeting common variations of the search query
• 3–5 internal links to related tools

Average position is finally moving. Lesson: SEO for tool sites is content + authority, not tool count.

Building everything from scratch

I tried to write a custom WASM PDF library. It took two weeks. PDF-lib already existed and was better. I wrote a video trimmer in raw WebCodecs API. FFmpeg.wasm did it in a tenth of the code.

For browser tools, the ecosystem in 2026 is mature. Use it. The "I built it from scratch" badge is worth less than shipping the tool a month earlier.

Mobile-first as an afterthought

50% of traffic to free-tool sites is mobile. Half my early tools assumed a 1280px screen. The fix wasn't responsive CSS — it was rethinking the workflow. On mobile, a "drag and drop your file" interface is useless. People tap, they don't drag. They want one button that opens the file picker.

If you're building utilities, design the mobile flow first.

The architecture that emerged

After 122 tools, the pattern stabilized:

┌─────────────────────────────┐
│  Static Next.js page (SSG)  │  ← SEO, fast first paint
├─────────────────────────────┤
│  Lazy-loaded tool component │  ← only loads when user interacts
├─────────────────────────────┤
│  Web Worker (when needed)   │  ← keeps UI responsive
├─────────────────────────────┤
│  WASM module (when needed)  │  ← for "real" processing
└─────────────────────────────┘

No API. No database. No queue. No auth. No Stripe. The whole site is static files served from a CDN. My infra cost is the domain and a Cloudflare account.

This is not appropriate for every product. It is appropriate for far more products than developers currently use it for.

When to stop being clever and just ship a backend

For honesty's sake, the in-browser approach breaks down for:

• Files >2GB — browser memory limits get awkward, even with streaming
• Long-running batch jobs — users won't keep a tab open for 20 minutes
• Anything requiring a private API key — you can't ship secrets to the client
• Heavy ML models — possible with WebGPU/ONNX but the UX still trails server inference

For everything else: try the browser-first version. You will be surprised how often it works.

What I'd tell past-me

1. Pick the boring tools first. A JSON to CSV converter ranks faster than a novel idea, because the search demand already exists.
2. WASM is not scary. Pick a library, copy the README, ship.
3. Don't build your own UI library. Use what exists. Spend the saved time on actual tools.
4. Static + client-side is a competitive advantage when your competitors are paying for servers.
5. Privacy isn't a feature you bolt on. It's an architecture decision you make on day one.

The web platform is genuinely capable now. A lot of "we need a backend for this" is muscle memory from 2015. It's worth questioning.

If you want to poke at any of the 122 tools, they're all here — none of them upload your files, all of them are free, and the source patterns above are the same ones running in production. Ask me anything in the comments.