I Built 20 Free PDF Tools with Next.js — Here's What I Learned (No Sign-up, No Watermarks)

Six months ago, I tried to merge two PDFs for a client proposal.

ilovepdf asked me to sign up. Smallpdf told me I'd hit my daily limit. Adobe wanted $20/month.

To merge. Two. Files.

That frustration turned into TryMyPdf — 20 completely free PDF tools, no account, no watermarks, files auto-deleted in 1 hour.

Here's the honest story of building it, the technical decisions I made, and what surprised me along the way.

What I Built

20 tools covering everything most people actually need:

Organise: Merge PDF, Compress PDF, Split PDF, Rotate PDF, Reorder Pages, Delete Pages, Resize PDF

Convert: JPG ↔ PDF, Word ↔ PDF, Excel ↔ PDF, PDF → PowerPoint, PDF → Text

Edit & Protect: Watermark, Password Protect, Unlock, Add Page Numbers, Header & Footer

All free. No limits. No account.

Tech Stack

Framework: Next.js (App Router)

Deployment: Vercel

PDF Processing: Server-side only — files never touch the client for sensitive operations

Storage: None — files are processed and immediately queued for deletion

I chose Next.js because:

1. API routes made it easy to handle file processing server-side
2. Vercel deployment is seamless
3. The App Router made it simple to build fast, SEO-friendly tool pages

The Hardest Technical Problem: File Deletion

The promise "files auto-deleted in 1 hour" sounds simple. It isn't.

Vercel functions are stateless — you can't run a background cron job inside a function. My solution:

// After processing, store deletion timestamp
await redis.set(`delete:${fileId}`, Date.now() + 3600000, { ex: 3600 });

// Vercel Cron runs every 15 minutes
// /api/cleanup/route.js
export async function GET() {
  const keys = await redis.keys('delete:*');
  const now = Date.now();

  for (const key of keys) {
    const deleteAt = await redis.get(key);
    if (now >= deleteAt) {
      const fileId = key.replace('delete:', '');
      await deleteFromStorage(fileId);
      await redis.del(key);
    }
  }
}

Files are gone within 15 minutes of the 1-hour mark. Not perfect, but honest.

What I Got Wrong First

Mistake 1: Client-side PDF processing

My first instinct was to process PDFs in the browser using pdf-lib. It worked for small files. For anything over 5MB, the browser tab would freeze or crash.

Moving to server-side processing fixed this — most tools now handle files up to 20MB without breaking a sweat.

Mistake 2: No progress indication

Early users thought the tool had crashed during compression. It hadn't — it was just working silently. Adding a simple progress bar reduced "is this broken?" support messages to zero.

Mistake 3: Assuming mobile users wouldn't use it

About 35% of my traffic is mobile. PDF tools on mobile are a nightmare with most services. Making the upload flow thumb-friendly was worth the extra week of work.

The Competitive Landscape

The PDF tool space looks crowded. But look closer:

The gap is real. People are genuinely frustrated with the incumbents.

What's Next

A few things I'm working on:

• OCR support — extracting text from scanned PDFs
• Batch processing — apply the same operation to multiple files at once
• API access — for developers who want to integrate PDF tools into their own apps

Lessons for Other Indie Hackers

1. Scratch your own itch — I built this because I was frustrated. That clarity helped me stay focused on what actually matters.

2. Ship fast, then iterate — The first version had 8 tools. I shipped it. Then added more based on what people actually asked for.

3. Privacy is a feature — "Files auto-deleted in 1 hour" is in the headline of every page. It converts skeptical users. Don't bury your privacy story.

4. Free works as a model if you plan for it — I'm not monetizing yet. But I'm building trust and traffic first. That's the plan.

Try It

👉 trymypdf.com

Also launched today on Product Hunt — would love your support: Product Hunt Launch

What PDF tool would you want added next? Drop it in the comments — I read everything.