From idea to launch in 2 weeks: How I built TinyPDF to solve my own job-hunting pain
Hey Indie Hackers đź‘‹
Two weeks ago, I was stuck: every job site had a different portfolio size limit — 2MB here, 5MB there, 10MB somewhere else. I'd spend 30 minutes bouncing between Photoshop and online compressors, guessing at quality settings just to hit that magic number.
Half the time the result looked terrible anyway.
So I did what any maker would do: I built a tool to solve my own problem.
The timeline
- Day 1-2: Validated the pain (asked 5 designer friends — all had the same problem)
- Day 3-5: Built the core compression logic (using canvas API for image downsampling)
- Day 6-8: Built the UI (kept it super simple — just drag, type a number, download)
- Day 9-10: Tested with 10 users, fixed edge cases
- Day 11-12: Added UTM tracking, set up error logging
- Day 14: Launched here on IH!
How it works
You upload a PDF, type the exact target size in MB, and it compresses to that size while preserving page count, page size, and layout — only dropping image quality as much as it has to.
All processing happens locally in the browser — no uploads, no account needed, free forever.
Current stats (first 10 days)
- ~200 unique visitors
- 45 PDFs compressed
- 12 genuine thank-you emails
- 0 revenue (but that's okay, it solves my problem!)
Would love to hear your thoughts: How do you validate side project ideas quickly?
Scratch-your-own-itch is how most of the tools I've built started, so this resonates. One thing you're underselling: you said the compression runs client-side via the canvas API. For this exact use case — people compressing resumes and portfolios — that's not a footnote, it's the pitch. Every other "free online compressor" means uploading a document with your name, your work, and often your contact details to some stranger's server. "Your files never leave your browser" is a real trust advantage and it costs nothing to say loudly on the landing page. I'd A/B the privacy angle against the size-limit angle — my hunch is job-hunters feel the privacy one more than they'll admit.
The strongest validation signal here is not that five friends agreed—it’s that 45 PDFs were actually compressed and 12 people cared enough to email you. Behavior beats polite feedback.
I’d still be careful with the “exact target size” promise. Some PDFs may not be compressible to the requested limit without becoming unreadable, so showing a quality warning or best-achievable size would build more trust than silently destroying the output.
For quick validation, I try to define one concrete action that proves the pain is real: uploading a file, completing a workflow, requesting access, or paying. Interviews help shape the hypothesis, but usage is what validates it.
Congrats on shipping! Validating with 5 people before writing code is the right instinct, and 2 weeks start-to-finish is a good sign you kept scope honest. Genuinely curious about the "free forever, no accounts" call: deliberate long-term choice, or leaving room to add accounts/pricing later if those 12 thank-you emails turn into repeat usage? I'm wrestling with a similar decision on my own project right now - how long you can stay free before it costs you (support load, hosting, or just the psychological switch) is a harder call than it looks from outside.
Scratching your own itch and shipping in 2 weeks is peak indie hacking! Local browser-side processing is a massive win for both speed and privacy, especially when handling personal documents like resumes and portfolios. Great breakdown of the launch timeline!
The file-based workflow is an interesting constraint because it changes how API requests are managed.
What would convince you that developers are actively looking for this workflow, rather than simply accepting the tradeoffs of existing API clients?