I thought building the PDF API was the hard part. It wasn't.

When I started PDFPipe, I assumed the difficult part would be the obvious stuff.

Running Chromium reliably.

Handling HTML rendering.

Making PDFs look identical everywhere.

Security.

Scaling.

Those were hard.

But they were not the hardest part.

The hardest part of building a developer tool is getting someone to care.

Because developers are not buying "a PDF API".

They are buying:

"I don't want to spend another weekend debugging why invoices broke."

"I don't want another service in my stack that only one person understands."

"I don't want to maintain a browser farm just to create documents."

The product is the easy part to explain.

The pain is harder to find.

The biggest lesson so far:

A good developer product solves a problem people already feel, not one you convince them they have.

The people who immediately understand PDFPipe usually have one of these:

a Puppeteer worker that randomly dies
a queue full of failed PDF jobs
customers asking for exports
invoices/reports as a core workflow

Everyone else just says:

"Can't I just use a library?"

And they are right.

If you generate 5 PDFs a month, you should.

The interesting users are the ones generating thousands.

That is where infrastructure starts making sense.

Current state:

API works
free tier is live
users are signing up
still hunting for the first real production workloads

The next challenge isn't writing code.

It is finding the teams already living with the problem.

If you run a SaaS that generates PDFs, what is your current setup?

Live on Product Hunt