A few weeks ago, I launched UniRecorder — a collection of 40+ free browser-based tools including a screen recorder, PDF tools, image tools, and calculators.
I built it solo from Pakistan. No team. No funding. No backend.
Here's what happened next.
The Numbers (Real Data from Google Analytics)
- 171 active users
- 164 new users
- 567 events (clicks, tool usage, downloads)
- Traffic from: Vietnam, Singapore, Hong Kong, Indonesia, Pakistan
My tools started ranking on Google — and users from countries I'd never targeted started finding them.
The Tech Stack (No Backend, No Frameworks)
Everything runs 100% in the browser:
- Vanilla JavaScript — no React, no Vue, no build tools
- MediaRecorder API — for screen recording
- Canvas API — for image processing
- jsPDF + pdf-lib — for PDF generation
- IndexedDB — for local video storage
- GitHub Pages — for hosting
No server. No database. No user accounts. No data collection.
The Problem I Was Solving
I got tired of tools that:
- Add watermarks to your recordings
- Limit you to 5 minutes
- Charge $50/year for basic features
- Upload your files to unknown servers
So I built my own. Then I kept building.
What 171 Users Taught Me
1. Tools rank faster than blog posts.
My most popular pages are tools, not articles:
- Image to PDF — 35 users
- PDF Merger — 33 users
- Image Compressor — 25 users
- Image Resizer — 13 users
Why? Because people search for "convert image to PDF" — they want a tool, not a tutorial.
2. International traffic comes automatically.
I never targeted Vietnam, Singapore, or Indonesia. But users from those countries found my tools because the need is universal — everyone needs to compress an image or merge a PDF.
3. Bounce rate is the real problem.
My bounce rate is 100% on every page. Users come, use the tool, and leave.
This is the next challenge: internal linking. I need to show users other tools they might need after they finish using one.
4. Local processing sells.
"Runs in your browser" isn't just a privacy feature — it's a performance feature. No upload time, no server queue, no waiting.
What I'm Building Next
- Internal linking between tools (reduce bounce rate)
- More blog posts (SEO + AdSense approval)
- Indie horror game "Wood" (Godot 4.2, releasing 2027)
The Hard Part Nobody Talks About
I built this on a broken laptop with no GPU. It takes 10-15 minutes just to boot up.
But the real challenge isn't the hardware. It's the patience.
SEO takes months. AdSense rejects you. Users don't come for weeks. And you have to keep building anyway.
Try the Tools
All 40+ tools are free. No signup. No watermark. No server.
If you're building something similar — or you have questions about the APIs — drop a comment. Happy to share more code.
Follow me here on DEV or connect on LinkedIn if you're interested in browser APIs, solo dev journeys, or indie game dev.
Top comments (4)
For anyone who wants to try the tools: unirecorder.online
All 40+ tools are free — no signup, no watermark, 100% private (runs locally in browser).
Would love feedback from other devs, especially on how to reduce bounce rate!
For bounce rate, I'd first separate "one-tool visits" from failed visits. Someone who lands on Image to PDF, finishes a conversion, and leaves may have got exactly what they needed. A useful test: instrument the completion/download event per tool, then show one contextual next step after it (e.g. compress the resulting PDF, if you offer that) rather than links while they're still working. Compare second-tool starts, not bounce rate alone.
You're absolutely right — I was looking at bounce rate the wrong way.
If someone lands on Image to PDF, converts their file, and leaves, they got what they came for. That's a success, not a bounce.
I'm going to:
The tricky part is the mapping. Image Compressor → Image Resizer makes sense. Word Counter → Currency Converter doesn't. So I'll need per-tool config.
Have you built something like this before? Curious how you structured it.
Thanks for the insight — this is exactly the feedback I needed.
I haven't built that exact 40-tool recommendation system, so I wouldn't claim a proven mapping. I'd start with a small per-tool config:
nextTool(or null) plus a completion event name, then fire the event only after a real output/download succeeds, not on button click. Keep a "no suggestion" option for tools without an obvious follow-on. That gives you a clean baseline before trying to optimize the pairs. Your Image Compressor -> Image Resizer example is a sensible first test.