We launched TinyPDF 3 weeks ago — here's what we learned about distribution as a designer with zero dev network

Listing what your tool can't do right in the launch post is underrated. It reads as confidence, not weakness, and it's probably why Indie Hackers converted so well for you.

The non-designer users aren't searching for your tool, they're searching for the limit that blocked them. A lawyer types the filing size cap, a student types the upload cap on the application portal. So I'd build one page per cap you can name, with the target-size field right there, since typing an exact MB number is the part generic compressors don't do.

The other half is showing up where people post the error, and those questions get asked in public daily, usually with the number in the title. A reply that solves it still reads fine with no link in it. That's most of the bet behind what I'm building right now, so discount accordingly.

Distribution with zero network is the real bottleneck, agreed. I'm about to launch a boilerplate on Gumroad and honestly the payment/payout setup took longer than expected as a non-US indie hacker. Would love to hear more about what channels actually converted for you beyond the initial post.

The interesting distribution lesson here may actually be a positioning lesson: with zero dev network, every acquisition channel has to do more than generate awareness—it has to quickly answer “why is TinyPDF worth switching to?” Distribution can get the product in front of people, but the landing page has to convert borrowed attention into a reason to try. I’d be curious whether your strongest acquisition sources are also the ones producing the highest activation, because a channel that looks weak on traffic can be much stronger if its audience arrives already understanding the problem TinyPDF solves.

On the momentum question: the biggest lever you already have is the moment the compressed file lands - that's the highest-attention second in the whole product, and right now it presumably just downloads. A quiet "made for the Behance 10MB limit - keep it" line with a copyable link there turns every successful compression into the next visitor, and it scales with usage instead of with launch spikes.

Second: your own numbers say the job is "hit platform X's size limit", not "compress a PDF". One landing page per platform ("Compress your portfolio to Behance's 10MB limit") matches the exact searches those designers type, ranks long-tail with almost no competition, and each page can honestly show the one number that matters for that platform. Generic compressor pages fight everyone; the per-platform job page fights nobody.

Also +1 on the honest-limitations list - it reads as confidence, and it's probably a big part of why IH converted so well for you.

I like the honesty in these learnings, especially the part about having zero audience and still finding traction by starting with people who had the exact same problem.

The UTM tracking point is easy to overlook too. It’s hard to know which channels are actually working when you’re posting in a bunch of places and relying on traffic numbers alone.

Getting around 1,200 visitors without spending a dime on ads in just three weeks is a great beginning. But the real challenge starts after that initial surge of interest. That's when things can get really interesting, especially when it comes to getting your content out to more people.

The honesty-about-limitations point extends further than most landing pages take it. I did the same thing inside the product, not just the marketing copy. Building Alisio, an invoicing app for freelancers, the tempting move is to always show a confident number, but I made mine say "sample too small to mean anything" rather than print a DSO figure that would mislead someone with three invoices. It felt like giving up a feature. It turned into the reason early testers trusted the numbers I did show. Same mechanism as your 80% designer-circle traffic: people extend more trust to something that admits its own boundaries than to something that claims to do everything. On the depth-vs-breadth question in the comments, I'd go deeper with designers before adding vocabulary for lawyers. A product obviously built for one group's exact words converts referrals; one diluted for five groups converts none of them well.

Congrats on the launch Nikoo! Your point about honest limitations building trust really resonates I noticed the same when launching calculatorspan a free time calculator tool. Transparency about what a tool can't do actually converts better than overselling.

On reaching non-designer users like lawyers and HR folks I'd suggest targeting those communities directly with pain-specific language. Instead of 'compress PDF', frame it as 'meet court filing size limits' or 'shrink HR documents instantly'. Same tool, different angle.

UTM tracking tip is gold —we implemented that early and it completely changed how we prioritized channels.

What's your current bounce rate looking like? That might help figure out where to focus next!"

Your UTM point is the one I'd underline, and there's a failure mode inside it I walked into this week.

Pasting a tracked link into a post is the easy case: you're writing the link, so you see it. The one that got me is the launch surface where the URL isn't something you paste but a field on a project record you filled in weeks earlier. I launched on a directory-style platform on Monday, and the project's website field was the bare domain, set long before I'd thought about campaign tracking. Nothing in the launch flow re-asks you for it. Four days of that channel's traffic went to direct/referral, and the one number I wanted (does this platform send anyone who actually signs up) is gone for those days. I only caught it by reading the page's own JSON payload, not from the UI.

So the checkable version of your rule: before a launch, list every place your URL is stored, not every place you're about to type it. Profile fields, project records, directory listings, the repo's homepage field, package metadata, email footers. The ones you type are fine. It's the ones you filled in months ago that quietly aggregate into "direct".

The 400 compressions number is the most interesting part. Before adding paid features, I'd look at what target sizes people choose and where failures happen. If one segment keeps asking for the same size limit, that can tell you which landing page or workflow to build next without guessing.

Listing what your tool can't do right in the launch post is underrated. It reads as confidence, not weakness, and it's probably why Indie Hackers converted so well for you.

Congrats on shipping with zero network, that is the hardest starting position there is. One distribution lane still wide open for utility tools: AI answer engines. People increasingly ask ChatGPT or Perplexity for a PDF merger or compressor directly, and the tools those engines name are the ones with clear structured data, consistent listings across directories, and pages that each answer one specific query. Free directory submissions still work for this, but read the fine print first. Many gate the dofollow link behind a badge or a fee, and plenty of the big household names are nofollow anyway. I track this for a living and the compounding effect of 10 to 15 clean listings is real. Happy to share which directories were actually worth the effort if that helps.

On reaching lawyers, students and HR people — the mistake that cost me the most time on a different product was assuming other segments search using my vocabulary. I run an AI headshot tool, and when I expanded it into Spanish and Polish, the literal translations of my best English keywords turned out to have almost no search volume. Those markets described the same need with entirely different words, and I'd built pages for phrases nobody typed.

The same gap exists between professions, not just languages. You think "compress PDF to an exact size". A lawyer thinks "court filing rejected my document". A student thinks "application portal won't accept my file". An HR person thinks "attachment too large for our system". Those are four different searches for one tool.

Worth pulling real search volume on a handful of those phrasings before building anything new — in my experience the answer is usually a separate landing page per phrasing rather than a new feature. Your product already does the job; the people who need it just don't know it exists under the name you gave it.

Also seconding your point about listing limitations. I do the same and it consistently outperforms a clean feature list.

Your startup is great. You have identified your users’ pain points very precisely, and I’m still searching for mine as well. Wishing you the best of luck!

400 compressions in three weeks gives you something much more useful than launch feedback — actual behavior.

Since most of the early traction came from designers who share the problem you originally built for, what are you seeing that makes you consider expanding to lawyers, students, and HR now rather than going deeper with the audience that's already using it?