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?
Hasn't tinypdf been around forever?
The strongest part of this story isn't actually the PDF tool — it's the moment that created it.
"Applying for jobs and struggling with this problem" is something people immediately understand. That kind of origin story can do a lot of heavy lifting because users connect with the frustration before they care about the features.
One thing I'd focus on is making sure the landing page leads with that pain, not just what the product does.
People rarely wake up thinking "I need a PDF tool." They think:
"I need to send a better application."
"I need my resume to look right."
"I don't want formatting issues to hurt my chances."
The closer the message gets to that real-life moment, the easier it becomes for the right users to say "this is for me."
The product is solving a practical problem — the opportunity is making the emotional reason to use it impossible to miss.
How did you get traffic ? By IH mainly I guess. Beyond your idea I feel the top challenge was : how to reach users quickly so that they try. I wonder how you solved that. As for product building it was really fast.
As I sit going over and over my own app idea and adding to the content on a daily basis this is a welcome reminder that by keeping things simple and focusing on the key problem you are trying to solve, not only does it enable a streamlined route to market but also avoids the project going off course. Thanks for sharing your own timeline and making me reconsider many of the things i'm currently trying to add in!
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?