What running our own product taught us about document-processing software

Most advice about building document-processing software comes from consultants who've only advised on it, not run it. PDFCourt (pdfcourt.com) is a PDF utility product we built and operate directly — merging, splitting, converting, and editing documents — and running it ourselves has been a useful, ongoing lesson in what this category of software actually demands.

The hard part isn't the happy path

The easy case (a clean, well-formed PDF) is straightforward. What actually costs engineering time is the long tail: malformed files, unusual encodings, and documents that technically validate but break a specific conversion path. Any real document-handling product spends the majority of its hardening effort here, not on the case that works the first time.

Frontend/backend boundaries need to be explicit, not implicit

When a product's frontend and backend are more tightly coupled than they need to be, the contract between them tends to stay implicit, until something on one side changes and breaks the other silently. Treating that boundary as an explicit, versioned contract from the start (even before it's strictly necessary) pays for itself the first time you need to change one side without touching the other.

"It works" and "it's fast enough under real load" are different milestones

Document conversion is CPU-heavy. A conversion that's instant in local testing behaves differently once real, concurrent usage shows up. That gap is easy to miss in development and expensive to discover in production.

What we'd tell a client running similar software

If you're maintaining anything that processes user-uploaded files, your test suite needs deliberately malformed, ugly inputs, not just clean examples. That's where production incidents actually come from, and it's the fastest way to close the gap between "it works in the demo" and "it holds up in production."

This is the kind of thinking we bring to modernization work for clients, informed by operating a real product ourselves, not just advising on one from the outside.