Series: Building PdfWord — a free, no-backend PDF tools site (Part 15)
"How much does it cost to run?" is the question I get most, usually followed by "...and how are you not losing money?" The answer surprises people: PdfWord — 36 tools, templates, a PWA, ~95 pages — costs me essentially nothing to run. No server bills. No database. No per-file processing fees.
This isn't a trick. It's an architecture decision with real tradeoffs, and I want to be honest about both sides.
Try it: PdfWord
Where the money doesn't go
Traditional PDF sites (the iLovePDFs of the world) have real infrastructure: upload servers, processing queues, storage for your files, CDN bills that scale with usage. Every file you convert costs them compute. That's why their free tiers have limits — the limits ARE the business model.
PdfWord has no backend at all. It's static files on Cloudflare Pages (free tier). Every tool is HTML + JavaScript that runs in your browser. When you merge two PDFs, my server does literally nothing — your phone's CPU does the work. My hosting bill is the same whether one person or one million people use it today.
The full cost stack:
- Hosting: Cloudflare Pages free tier — $0
- Domain: none yet (it's on a pages.dev subdomain) — $0
- Build/CI: none, I deploy from my laptop — $0
- Total monthly burn: $0
The libraries that make it possible
This architecture only works because the browser PDF ecosystem is genuinely excellent now:
- pdf-lib — create and modify PDFs (merge, split, watermark, metadata)
- pdf.js — render pages (viewing, thumbnails, the compare tool's pixel diff)
- SheetJS — Excel read/write in the browser
-
Tesseract.js — OCR, entirely client-side (with the
.traineddata.gzgotcha from Part 8's era — ship both files)
Nine libraries total, all served locally, zero CDN dependencies. The whole thing works offline once cached (Part 10). A PDF site with no server is only possible because these libraries exist and are good.
What "free" actually costs me
Money: nothing. But zero-backend is not zero-cost. Here's what I actually pay:
- Development time. Every feature is client-side engineering — no "just throw it on the server." The Split by Size bin-packing (Part 13) and the PDF editor's three rewrites (Part 14) were weeks of work each. Server-side would have been easier for some of these. I chose the harder path for the privacy story: your files never leave your device isn't marketing copy, it's the architecture.
- The 50MB file limit. Browsers run out of memory on enormous files. A server with 64GB of RAM could chew through a 2GB PDF; a phone browser cannot. The limit is honest and stated everywhere, but it's a real capability ceiling.
- No user accounts, no sync. Without a backend there's nowhere to store "your files" or "your history." The Recently Used strip is localStorage. That's a feature for privacy and a limitation for convenience, and I won't pretend otherwise.
- SEO is harder. A static site with client-rendered tools needs real content pages for Google to index — hence the 95-page sitemap, the guides, the FAQ schema. The tools themselves are invisible to search engines; the content around them does the ranking work.
The business model question
Right now there isn't one — it's free, no ads, no tracking. The plan is AdSense once traffic justifies it, which is exactly why Parts 1–15 of this series exist: every article is a backlink, every backlink is authority, every ranking page is traffic.
Is "build free tools, rank on Google, monetize with ads" a good business? It's the oldest playbook on the internet. The twist is just the cost structure: at $0/month burn, I don't need venture scale. A few thousand daily users and modest ad revenue makes it sustainable. The bar for "this works" is refreshingly low.
What I'd tell anyone considering zero-backend
- Do it when the work is CPU-bound, not data-bound. PDF processing is perfect: the compute happens wherever the file is. Don't do it for anything needing shared state.
- Your constraints become your marketing. "No signup, no upload, works offline" isn't a feature list I invented — it's what falls out of having no server. Lean into it.
- Budget for the content. The tools took months; the SEO content (guides, comparisons, landing pages) took weeks more. Invisible tools don't rank.
- $0 burn is a superpower. It means you can be patient. No runway, no panic, no premature monetization that ruins the thing.
Fifteen parts in, the site is 36 tools, 95 pages, zero backend, zero dollars a month. The next chapter is traffic — and you're reading part of the strategy right now.
Try it: PdfWord — 36 free tools, no signup, no watermark.
What's the cheapest thing you've ever run in production? I want to hear about your $0/month architectures.
Top comments (0)