I Built 24 Free Browser Tools in 6 Weeks — Here's What I'd Do Differently

#webdev #javascript #indiehackers #startup

Six weeks ago, I had zero browser tools. Now I have 24. Revenue: $0.

This is not a success story. It's a reality check on what happens when you focus on building and ignore distribution.

What I Built

24 tools, each a single HTML file with vanilla JavaScript. Hosted on GitHub Pages. No server, no database, no frameworks.

Hub: 24 Free Browser Tools

The tools span four categories:

PDF & Document: Merge, split, convert, extract — 7 PDF tools
Image: Compress, resize, crop, AI background remover, color picker
Developer: JSON-CSV converter, text diff, base64 encoder, UUID generator, markdown editor
Productivity: Password generator, QR codes, timestamp converter, case converter, word counter

All running client-side. Your files never leave your browser.

What Went Right

1. Single HTML File Architecture

No build step. No npm install. No node_modules. Each tool is one file:

<!DOCTYPE html>
<html>
<head>
  <style>/* all CSS inline */</style>
</head>
<body>
  <!-- all HTML -->
  <script>
  // all JavaScript
  </script>
</body>
</html>

This means: instant deploys, zero dependencies, trivially auditable. Users can view source and confirm nothing shady is happening.

2. Browser APIs Are Incredible Now

Canvas API — Image compression, resize, crop. All at native speed.
Web Crypto API — crypto.getRandomValues() for true-random UUIDs and passwords.
WebAssembly — Runs a full AI neural network for background removal. ~5 seconds per image, no cloud GPU.
EyeDropper API — Pick any color from your screen.

I didn't need a single server-side dependency. The browser IS the platform.

3. Free Hosting That Scales

GitHub Pages: free, global CDN, auto-deploys on git push. Even if 100,000 people use a tool simultaneously, GitHub's CDN handles it without me paying a cent.

What Went Wrong

1. I Built Too Many Tools

24 tools is too many. Each one needs:

A blog post for SEO
A Gumroad product listing
Cross-links to other tools
Testing across browsers
Bug fixes

That's 24 x 5 = 120 tasks just for maintenance, before any promotion.

If I could start over: build 5 really good tools instead of 24 decent ones.

2. Distribution Is 10x Harder Than Building

Coding 24 tools took 6 weeks. Getting anyone to use them? That's the real work.

My promotion efforts so far:

4 dev.to articles (this is #5)
Hacker News Show HN (0 upvotes)
Reddit posts (0 comments)
Directory submissions (pending review)

Building something is the easy part. Getting distribution is the entire game.

3. Free Is a Bad Marketing Strategy

"It's free!" sounds great until you realize it means "no urgency to buy." My free limits are generous — most users never hit them. This is great for users, terrible for revenue.

If I could restart, I'd make the free tier slightly more restrictive and add a free trial of PRO features.

4. No Email Collection

I have no way to contact users. No newsletter, no onboarding email, no "we miss you" automation. Every user who visits is a one-time event. If they don't buy immediately, I never see them again.

Adding a simple "Save your work" feature that requires email would have changed everything.

5. Zero Social Proof

Nobody wants to be the first person to buy something. The bundle page has no reviews, no testimonials, no "X people bought this." It's empty. Social proof is the strongest conversion lever, and I have none.

The Tech That Surprised Me

ONNX Runtime Web for background removal. A full neural network running in WebAssembly, in the browser, with no API key. The model is ~40MB but caches after first load. Processing takes ~5 seconds. This shouldn't be possible in a browser, but it is.

pdf-lib for PDF manipulation. Pure JavaScript, no native dependencies. Handles merge, split, page extraction, metadata. The API is surprisingly clean.

Service Workers. I didn't implement them, but all these tools would benefit from offline-first architecture. Next priority.