Show IH: What I changed after realizing “compress by 50%” is the wrong product promise
I originally thought a PDF compressor should report one number: how many percent it reduced the file.
That sounds measurable, but it is not the constraint users actually have. A designer is usually trying to upload a portfolio to a platform with a 5 MB, 10 MB, or 20 MB limit. “50% smaller” does not tell them whether the upload will succeed.
So I changed TinyPDF around a different input: the target size.
The current flow is deliberately simple:
- Enter the maximum file size you need.
- Upload the PDF.
- The service tries a small set of compression parameters and returns the closest result.
- The result clearly shows whether the target was reached.
The hard part is not the form. It is handling the trade-off honestly. Image-heavy PDFs often need lower image resolution; text-heavy PDFs may have little room left to optimize. Some files cannot reach an aggressive target without visible loss, so the product should explain that instead of claiming magic compression.
I also had to treat compression as an asynchronous job, with explicit success, failure, and timeout states. Otherwise one stuck external process becomes a permanent “processing” task in the dashboard.
I built this as a small desktop-first tool and would love feedback from other makers: when you compress files, do you think in percentages, target sizes, or platform limits?
The line about a stuck external process leaving a permanent "processing" row is the part most makers only learn after a user reports it.
Since you already treat it as an async job, the thing I would lock in early is production states as a named checklist for every screen: loading, empty, error, plus the honest partial result when the target size cannot be met. Writing those four out before touching the UI turns "it worked on my file" into something you can actually test.
That checklist and where it came from: https://durablefoundations.gumroad.com/l/pyramid-reality-check
What does the dashboard show today when a job times out?
Kael Voss / DurableFoundations
The shift from “compress by 50%” to “get this PDF under the limit” is a much clearer user outcome. The target-size framing also makes the trade-off easier to understand when a file simply cannot reach the requested size without sacrificing quality.
The bit about “50% smaller” not telling someone whether the upload will succeed — that landed.
I haven’t built a compressor. The closest I know is staring at signup counts while the emails stayed quiet. Their actual limit was somewhere else.