I built a PDF API because every team I know has a haunted corner of their codebase they never want to open
I kept seeing the same thing across every engineering team I talked to
Not a monolith. Not tech debt in the classic sense. Something more specific: a PDF service that nobody wrote on purpose.
It started as a one-off. Someone needed invoices. They found a library, wired it up, shipped it. It worked. They moved on. Six months later the fonts are wrong on Windows. A year later it breaks under load. Two years later the person who built it is gone and nobody knows how it works.
Every team has one. The PDF corner. The thing that runs fine until it doesn't, and when it doesn't, it is always a Friday.
I built PDFPipe to be the other option.
What it is
One API endpoint. POST your HTML, get a PDF back. Under 3 seconds, pixel perfect, sandboxed. That is it.
curl -X POST https://api.pdfpipe.xyz/v1/pdf \
-H "Authorization: Bearer YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"html": "<h1>Hello</h1>"}' \
--output hello.pdf
No render engine to operate. No font wrangling. No queue to babysit. You send HTML, you get a PDF.
SDKs for Node and Python. An MCP server if you are building agents. An n8n node if you are doing automation. Works wherever you can make an HTTP call.
The pricing
Free tier: 500 documents a month, forever. No card. No trial. No expiry. Just a key and a limit.
Paid starts at $19/month (3,000 docs), goes up to $499/month (100,000 docs). Enterprise is custom. The free tier is genuinely usable, not a 7-day teaser.
I set it at 500/month because that is roughly 10x what most "free tier" API products give you. If you are testing something, 500 documents is enough to actually know if it works for your use case.
Where I am
Zero paying customers. I launched publicly a few weeks ago and I am at the stage where the product works but nobody knows it exists.
The API is live. The free tier has signups. I have not converted any of them yet.
I am writing this partly because Indie Hackers is where I would want to find something like this if I were on the other side, and partly because I think the honest version of a launch post is more useful than the one where someone skips from "I had an idea" to "here are my MRR graphs."
Right now I am doing cold outreach to SaaS products that generate PDFs as part of their core workflow. HR platforms. Field service tools. EdTech. Legal tech. Every one of these teams has the same problem and most of them are running something they built once and never want to touch again.
I do not know yet if this works. I will post an update when I have something real to report.
"It always breaks on a Friday" — that's painfully accurate for any haunted service. The PDF corner exists in every codebase I've ever touched too.
The honest launch post angle resonates. I'm in a similar spot with knallhart[.]dev — product works, distribution is the hard part. Zero to first paying customers is its own problem set entirely.
What's your conversion rate looking like from free tier signups so far? Even directionally.
None yet, Have been trying to crack distribution, I have no idea how to approach that, would love any help i can get on the distribution part
"The PDF corner" is surprisingly relatable. A lot of infrastructure only gets attention when it breaks, so I can see why teams would rather outsource that complexity.
The "haunted PDF corner" framing is exactly right. Every codebase has one.
We ran into this building Swiftbill — an invoice generator for freelancers. Ended up going the opposite direction and doing PDF generation entirely client-side with pdf-lib so invoices never touch a server. Solved the privacy concern (freelancers didn't love the idea of their client data hitting a backend), but pdf-lib is a whole different kind of pain: no real font support, layout is all manual math, no HTML-to-PDF shortcut.
For most teams the server-side HTML-to-PDF path is genuinely the right call. The moment you need conditional page breaks or complex tables, doing it by hand in pure JS becomes its own haunted corner. A clean API with predictable output would have saved us weeks.
Would you use this platform?
"It always breaks on a Friday" made me laugh because it's painfully true. The haunted PDF corner is such a perfect way to describe it. Also respect for posting the real $0 version instead of an MRR graph.
Thank youuu
The "haunted corner" framing is exactly right. Every team has one. PDF is the classic because the failure mode is always delayed and the person who built it is never there when it breaks.
The "it works until it doesn't, and when it doesn't it's a Friday" is one of the more honest product descriptions I've seen on here. That specificity is what gets engineers to pay attention. Not the feature list.
One thing worth testing early: the buyers for a PDF API inside a company are usually not the engineers who encounter the problem. It's whoever owns the finance or legal workflow that depends on it. The engineer raises the flag, but someone else writes the check. Worth thinking about how you reach both.
Thank you so much, I've been trying to reach developers didnt think about the legal/finance side of things
That's a common split in B2B. The person who feels the pain and the person who approves the budget are usually different people. Engineers flag the problem, but finance or legal owns the workflow and writes the check. If your messaging only speaks to developers it may get interest but not purchase. Worth building two versions of your pitch early.
Got it thanks
One thing I'd be careful with:
The interesting question may not be whether engineering teams have this problem.
It may be which teams feel it strongly enough to replace what they already have.
Those sound similar, but they tend to create very different signals once outreach starts.
I wouldn't make that call casually this early.
Yeahh, I have no idea how to go about distribution, I can build but Getting it to market has been a real task for me
Possibly.
The reason I'd still be careful is that I don't think the interesting challenge is distribution by itself.
I think there's a more important decision sitting underneath it.
That's one of those things that can make outreach feel ineffective even when the activity itself is reasonable.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll put together the tighter version.
[email protected]
Sent you a note by email.
I think the decision underneath the distribution question matters more than the distribution tactics themselves.