We built 99 business tools that never upload your files
Every small-business tool on the internet follows the same pattern: you upload a file, it processes it on a server, and you trust a stranger with your bank statement, your client list, or your contracts. We got tired of
Every small-business tool on the internet follows the same pattern: you upload a file, it processes it on a server, and you trust a stranger with your bank statement, your client list, or your contracts.
We got tired of that pattern, so we built 99 tools that keep the file on your device. Everything runs in the browser tab. Here is how that actually works, technically.
The stack is boring on purpose
No framework runtime in the processing path. Most tools are a single HTML page with vanilla JS. The heavy lifting comes from libraries compiled to WebAssembly or built for the browser:
- PDF work (merge, split, compress, redact, sign): pdf-lib and PDF.js, all client-side
- OCR: Tesseract.js running in a Web Worker so the tab stays responsive
- Background removal: an ONNX model running via onnxruntime-web with the WebGPU backend when available
- File parsing: SheetJS for the spreadsheet-heavy tools (bank CSV to QuickBooks QBO, settlement reconcilers, payout summaries)
The pattern per tool: read the file with the File API, process in memory or in a worker, hand back a Blob URL for download. No fetch() with your file ever fires. You can watch the network tab - after the page loads, it goes silent.
Why workers matter more than WASM
WebAssembly gets the attention, but the Web Worker is what makes a 40MB PDF merge feel like a native app. Every long task runs off the main thread. The UI stays at 60fps while Tesseract chews through a scanned contract.
The trickier part is memory. A 200-page scanned PDF as an ImageData buffer will happily eat 2GB. We process page-by-page and release buffers aggressively - the boring kind of engineering nobody blogs about, but it is the difference between "works in the demo" and "works on the bookkeeper's five-year-old laptop".
Local persistence without accounts
No signup means no server-side storage, so drafts live in IndexedDB. The resume builder, the shop till, the repair tracker - close the tab, come back next week, your data is there. It never left.
The honest tradeoff: clearing site data wipes your drafts. We say so on the page. Local-first means the user owns the data, including the responsibility for it.
What we learned
- Browser compute is genuinely enough now. WebGPU and WASM SIMD closed the gap for the jobs small businesses actually have.
- "No upload" is a feature people check. The network tab is the marketing page.
- Single-file tools are a distribution superpower. Each one is a URL that works instantly, no install, no signup friction.
The tools are at https://xargaar-tools.pages.dev/ - all free in the browser, funded by optional offline packs. Full disclosure: we are the makers, and we build with heavy AI assistance (which is how a tiny team ships 99 of these).
Happy to answer questions about the WASM/worker setup in the comments.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.