Essay

Why I built PDFops

2026-05-11 · ~6 min read

I run several SaaS businesses. Across every one of them, there's a moment that always comes — usually a few weeks in — when I need to generate PDFs. Invoices for a billing flow. Filled forms for an onboarding step. Signed contracts. Inspection reports. Receipts. It never seems like it'll be a big problem, until I sit down to do it.

Then it's a big problem. Hosted PDF APIs (DocRaptor, PDFShift, PDFMonkey) charge $0.05 to $0.20 per document — fine in a spreadsheet, brutal in a system that generates 50,000 a month. Self-hosting a PDF library means running a Node or Python backend, which clashes with the rest of my stack being on modern edge platforms. Headless Chrome on Lambda works — until it doesn't, somewhere around the third weird font issue or the first time the cold-start latency wrecks a checkout flow.

After hitting that wall enough times, I built it once, as a hosted API. Now I use it across every business. Then I started talking to other operators and realized I wasn't the only one — the same PDF-shaped wall sits in front of every multi-product founder I know. So I cleaned it up and made it self-serve.

What it is, in four bullets

Hosted PDF API, globally distributed. Sub-100ms response times wherever your traffic is. No region config, no VPC tuning, no warm-pool sizing.
Three endpoints today: POST /api/fill-form (fill PDF form fields), POST /api/merge (merge N PDFs into one), and POST /api/waitlist (sign up for higher tiers).
Free during beta. 100 requests per IP per month, no auth, no signup. If you can type curl, you can use it.
Designed to be roughly 10× cheaper than incumbents when pricing lands post-beta. The unit economics work because the platform PDFops runs on isn't where the incumbents priced their margins from.

Try it

Pull any PDF with form fields off your desktop, swap the field-name JSON below, and run:

curl -X POST https://pdfops.dev/api/fill-form \
  -F "pdf=@invoice-template.pdf" \
  -F 'fields={"customer_name":"Acme Co","total":"$1,250.00"}' \
  -o filled.pdf

You get a filled PDF back. No auth header. No signup. 100 requests per IP per month are free during beta.

Need to merge a couple of PDFs into one?

curl -X POST https://pdfops.dev/api/merge \
  -F "pdf=@cover.pdf" \
  -F "pdf=@body.pdf" \
  -F "pdf=@appendix.pdf" \
  -o combined.pdf

Both endpoints should just work the first time. If they don't, the waitlist form doubles as a bug-report channel until there's a proper issue tracker.

Why this is cheaper than what you're using

Existing hosted PDF APIs priced their margins on top of a hosting substrate that's roughly an order of magnitude more expensive than what's available today. They shipped years before that substrate existed. Their pricing reflects their costs, not their value, and nothing about $0.05-0.20 per document is fundamental.

PDFops is built on a newer hosting tier with materially different unit economics. The savings pass through. Getting a PDF operation to actually run on that newer tier — and to deploy globally without re-platforming per region — took longer than I expected. Once it works, it works.

That's it. The market just hasn't repriced PDF generation against current hosting costs yet, because the only people positioned to do it are the ones using it for their own products first.

What's not there yet

This is an MVP. I'm publishing the thinnest useful version on purpose, so I can find out what to build next from people who actually use it instead of guessing.

More endpoints: /stamp, /watermark, /sign, /extract-text, /redact. Vote on the waitlist form for which one matters most for your use case.
Pricing tiers. Right now everything is free, capped at 100 requests per IP per month. Soon it'll be free + paid, with the free tier sized to cover real side-project usage.
A dashboard. Currently API-only. You get back PDFs; you don't get a UI to look at quota or recent calls. The waitlist form measures whether that matters.

Waitlist

If you'd use a paid tier — more requests, more endpoints, a dashboard, support — join the waitlist. A few quick questions help me figure out what to build next and which features actually justify their build cost. The waitlist is the only way features get prioritized; nothing on the roadmap above is committed until I see real demand.

← All posts · PDFops home