PDF Pony has 145 tools. It processes everything in the browser — no server uploads, no accounts, no subscriptions. It supports digital signatures with full PKI, OCR, print production preflight, and works offline. I built it in under a week.
That statement would have been absurd two years ago. It is true now because of how AI-assisted development has changed what a single developer can do. But the story of building PDF Pony is not really about speed. It is about what happens when the bottleneck shifts from writing code to understanding problems.
Building with Claude Code: from description to working tool in minutes#
My primary development tool was Claude Code. The workflow was straightforward: describe what a tool should do, review the output, test it, refine it. For most of the 145 tools, the code generation was fast and accurate. The JavaScript ecosystem for PDF manipulation is mature enough that the underlying operations — parsing page trees, manipulating content streams, compressing objects — have well-established patterns.
What Claude Code changed was the ratio between thinking and typing. I could describe a tool’s behavior in plain language and get working code back in seconds. The cycle time from idea to functional implementation dropped from hours to minutes. Across 145 tools, that compression is the difference between a week-long project and a months-long one.
Why understanding 145 use cases was harder than writing the code#
But here is what surprised me: the code was the easy part. The hard part was understanding each use case well enough to build something that was actually useful — not just functional.
Take Bates numbering. The implementation is simple: add sequential identifiers to every page of a document. But to build a tool that a legal professional would actually use, you need to understand the conventions — prefix formats, zero-padding, starting numbers, placement on the page, font sizing, what happens when you Bates-number a document that already has page numbers. Getting the code to stamp text on a page takes ten minutes. Understanding the context well enough to make good default choices takes much longer.
The same pattern repeated across all 145 tools. The invoice generator needed to understand that different industries expect different layouts, that tax calculation varies by jurisdiction, that currency formatting is not just a symbol swap. The print production tools needed to reflect how prepress professionals actually think about crop marks, bleed areas, and ink coverage. The digital signature tools needed to implement a complete PKI workflow — not just stamp a visual signature on the page, but generate real keypairs, create certificates, and produce cryptographically verifiable signatures.
For each tool, the question was never “can I generate code that does this?” It was “do I understand this use case well enough to make the right design decisions?” That meant researching workflows, reading standards documentation, and testing each tool against real-world scenarios — not just happy-path inputs.
Client-side architecture, offline support, and internationalization#
A few technical decisions shaped the project.
First, everything runs client-side. This was a firm constraint from the beginning, not an optimization. If files never leave the device, there is nothing to worry about from a privacy standpoint. It also eliminates server costs almost entirely — the browser does all the computation, so hosting is just static file delivery.
Second, the application works offline. After the initial load, all 145 tools are available without an internet connection. This is a natural consequence of the client-side architecture — if the browser has the code, it does not need the server.
Third, internationalization was built in from the start. PDF Pony is available in five languages with fully localized URLs — not just translated UI strings, but proper localized paths for every tool. This was a deliberate decision to reach users globally, and doing it from the beginning was significantly easier than retrofitting it later.
Building a 359-term PDF glossary as a reference resource#
One thing I did not expect to build was a 359-term PDF glossary. But as I worked through the tools, I kept encountering concepts that even technically literate users would not know — PKCS#12 containers, cross-reference tables, CIDFont subsets, ICC color profiles. The glossary started as notes for my own reference and grew into a standalone educational resource organized across 24 categories. It now serves as both documentation for the tools and a comprehensive reference for anyone working with PDFs.
AI-assisted development amplifies domain knowledge, not replaces it#
Building PDF Pony reinforced something I have observed across several projects now: AI-assisted development does not eliminate the need for domain knowledge — it amplifies its value. When code generation is cheap and fast, the differentiator is knowing what to build and why. The developer who understands the problem space deeply will build something better than the developer who prompts faster.
It also reinforced the economics of client-side architecture. PDF Pony costs almost nothing to host. There are no servers processing files, no storage costs, no compute bills that scale with usage. The entire cost structure is static file delivery. This means the project does not need to restrict access or push users toward subscriptions to cover infrastructure costs — which means the incentives are aligned with the user, not against them.
A year ago, a solo developer building 145 specialized tools was not a realistic project. The surface area was too large, the implementation time too long. That constraint has changed. What has not changed is the requirement to understand the domain, to make thoughtful design decisions, and to care about whether the end result actually works for the people who use it. AI handles the typing. The thinking is still the job.
