100 Days, 87 Tools, Zero Servers
I spent 100 days building ToolKnit. It is a suite of 87 browser-based tools.
Most tool sites work like this:
- You upload a file.
- A server processes it.
- You download the result.
This means your sensitive PDFs and photos sit on someone else's server. I wanted a different way. Every tool in ToolKnit runs entirely in your browser. No files leave your device.
Here is what I learned about building without a backend.
The Stack
- HTML and Tailwind CSS.
- Vanilla JavaScript.
- PHP for simple stats only.
- Zero frameworks. No React. No Vue.
Why Static HTML?
- SEO is better. Google crawls static pages instantly. There are no hydration delays.
- Speed is higher. Users get tools immediately. They do not wait for large JavaScript bundles to load.
- Costs are low. I use almost no server power.
The Challenges Building 87 pages without components is hard. If I change a footer link, I have to edit 87 files. I had to write Python scripts to manage this.
I learned the limits of the browser:
- PDF compression is hard. It requires complex stream manipulation to avoid file corruption.
- Audio synthesis is deep. Making a realistic piano sound requires multiple oscillators and custom harmonics.
- Video is heavy. Using ffmpeg.wasm works, but the 32 MB download is a burden for slow connections.
My Biggest Lesson Kill features that almost work.
I built a tool for iPhone Live Photos. It had three major flaws:
- The math for rounded corners was wrong in the Canvas API.
- Video transcoding took too long.
- Apps like WeChat stripped the data I needed.
A tool that is 90% functional erodes trust. If it is not great, do not ship it.
What is Next? I am now building a desktop app using Tauri and Rust. It will follow the same rule: all processing stays local.
Summary of the 100-day build: • 87 tools shipped. • 3 tools killed. • 0 framework dependencies. • 3,000+ total uses.
Are you building client-side tools? Tell me about your architecture in the comments.