How I Built TurboUtil: A Side Project Story
TurboUtil started as a weekend project born from frustration. Here's the honest journey from idea to 200,000+ monthly users — including the mistakes, technical choices, and lessons learned.
The Problem That Started It All
Late 2024, I was working on a fintech project in Singapore. We were handling sensitive financial data, and I needed to decode a JWT token to debug an authentication issue.
I opened my browser, typed "jwt decode", and reached for the top result — then stopped. Should I really be pasting customer authentication tokens into a random website?
I checked their privacy policy. Buried in legal jargon was a clause about "collecting usage data to improve services". Were they logging my JWTs? Probably not intentionally... but maybe?
The Aha Moment: I realized I — and probably millions of other developers — were trusting random online tools with production secrets every single day. That felt wrong.
Version 1: Halloween Weekend Hackathon
I spent Halloween weekend 2024 building the first version. Just three tools:
- • JWT Decoder
- • JSON Formatter
- • Base64 Encoder/Decoder
The entire site was a single HTML file with vanilla JavaScript. No framework, no build process, no analytics. Just pure client-side code that did exactly what it said and nothing more.
First Version Tech Stack:
- • Single
index.htmlfile (~800 lines) - • Vanilla JavaScript (no dependencies!)
- • Tailwind CSS via CDN
- • Hosted on GitHub Pages (free)
- • Domain: turboutil.app ($12/year)
Total cost: $12/year. Perfect for a weekend experiment.
I posted it on Reddit's r/webdev. Expected maybe 50 upvotes. Woke up to 2,400 upvotes and the site on the front page. My $0/month GitHub Pages hosting was... struggling.
Growing Pains: Scaling to 50,000 Users
Within two weeks, I had Feature Requests flooding my GitHub issues:
- • "Add UUID generator!"
- • "Can you make an image resizer?"
- • "Dark mode please!"
- • "Timestamp converter would be amazing"
The single-HTML-file approach wasn't going to scale. I needed a proper framework. But which one? And how could I maintain the core promise: 100% client-side, zero tracking, works offline?
The Big Rewrite: Moving to Next.js
December 2024, I rebuilt everything in Next.js. People asked: "Wait, Next.js is for server-side rendering. Doesn't that contradict your privacy-first approach?"
Not quite. Here's the trick: Next.js Static Export.
How TurboUtil Uses Next.js:
- 1. Build time: Next.js generates static HTML/CSS/JS files (no server required)
- 2. Deploy: Static files deployed to Vercel Edge Network (CDN)
- 3. Runtime: All tools run in your browser using React. Zero backend calls.
- 4. Offline: Service Worker caches everything for offline use
Result: Framework benefits (React components, routing, TypeScript) without sacrificing privacy.
Current Tech Stack (2026):
Frontend
- • Next.js 15 (Static Export)
- • React 19
- • TypeScript
- • Tailwind CSS
- • Lucide React (icons)
Infrastructure
- • Vercel (hosting & CDN)
- • Cloudflare (DNS)
- • Service Worker (offline)
- • GitHub (source control)
Challenges & How I Solved Them
Challenge #1: Image Processing
Problem: Users wanted image tools (resize, compress, convert). But browser image processing can be slow and memory-intensive.
Solution: Used HTML5 Canvas API with Web Workers for multi-threaded processing. Images never leave the browser, but processing happens in background threads so UI stays responsive.
Challenge #2: SEO Without Server
Problem: Static sites can struggle with SEO. Each tool page needed unique meta tags, descriptions, and structured data.
Solution: Next.js's static generation handles this perfectly. Each page gets pre-rendered with proper metadata at build time. Google sees fully-formed HTML.
Challenge #3: Monetization Without Tracking
Problem: Server costs (even for static hosting) aren't zero. Need revenue, but can't use intrusive ads or sell user data (that's the whole point!).
Solution: Google AdSense with strict privacy settings. Ads are contextual (based on page content, not user tracking). Not ideal, but transparent and compliant.
Challenge #4: Keeping Load Time Fast
Problem: As I added more tools, bundle size grew. Client-side apps can get bloated.
Solution: Code splitting! Each tool is a separate route with lazy-loaded components. You only download JavaScript for the tool you're using. Home page loads in <1 second.
What I'd Do Differently
Looking back after 16 months, here's what I learned:
- Start with a framework: The rewrite from vanilla JS to Next.js was painful. Should've started with React from day one.
- Add PWA earlier: Users kept asking "can I install this?" Took me 6 months to add PWA support. Should've been there from the start.
- Document everything: GitHub issues became my informal documentation. Wish I'd written proper docs earlier.
- Don't underestimate SEO: Spent too long focused on features, not enough on discoverability. Content and blog should've come sooner.
By The Numbers (March 2026)
Monthly active users
Different tools available
User data collected
Monthly hosting cost (Vercel)
What's Next?
TurboUtil is still a side project, but it's become something bigger than I imagined. The roadmap includes:
- • More developer tools (request them on GitHub!)
- • Mobile app versions (same privacy guarantees)
- • Open-source the codebase (still cleaning it up)
- • API for developers who want to self-host
Thank You
To everyone who uses TurboUtil, reports bugs, requests features, or just shares it with colleagues — thank you. You've turned a weekend project into something that actually helps developers worldwide.
And to those reading this thinking "I could build something like this" — you absolutely should! The web needs more privacy-first tools. The tech is available, the users are out there, and the world is better when developers build things that respect people.
Follow the journey: turboutil.app