PDF pre-processor for large-file workflows

The moment someone has a 200-page scanned PDF they need to edit, combine, or sign and their PDF editor either freezes mid-task or crashes without logging an error, they realise their tool was never designed for that file. They lose work, restart the computer, and either try again or give up.

This gap persists because the major PDF editors are optimised around the median file — a 10-page contract or a short report. Large-file performance requires fundamentally different rendering and memory management, and fixing it inside a product that already ships to millions of users means risking regressions everywhere else. The vendors have no structural incentive to prioritise it: their pricing isn't tied to throughput, and most support tickets about large-file crashes get closed with 'try reducing file size first.'

What users actually need isn't a better viewer — it's something that strips a bloated PDF down to a workable state before it ever touches their editing software. Complaints reference 'digitally signed PDFs taking too much time to load,' 'graphics-heavy PDFs consuming significant RAM,' and 'combining large PDFs causing the application to hang and fail to generate the file.' The problem isn't the editing step — it's arriving at that step with a file that's already too heavy.

A tool that accepts an oversized PDF, identifies what's inflating it (embedded fonts, redundant layers, uncompressed scans, unnecessary metadata), and produces a lean working copy — without touching the content — would slot in before the editing workflow, not replace it. Users keep their existing editor; they just stop fighting it.

This is a business and not a feature because the need recurs every time someone receives a large file they didn't create. Document-heavy teams — legal, engineering, compliance — deal with this weekly. The cost without it is real: lost work from crashes, time spent reinstalling software, and delays in time-sensitive tasks where 'lag during urgent use' (a direct complaint) is genuinely expensive.

What to build

Build a desktop-native CLI and drag-drop GUI that ingests oversized PDFs, diagnoses the specific inflation sources (layer count, image DPI, embedded asset bloat, scan compression), and outputs a reduced working copy with a diff report showing what changed and what was preserved.

Where to start

Start with scanned PDF files specifically — uncompressed scan stacks are the single most common cause of the 'freezes on open' complaint, they have no legal sensitivity around compression, and the size reduction is dramatic enough to be immediately convincing in a demo.

The hard part

The hardest early problem is accurately predicting which optimisations are safe — stripping the wrong layer or recompressing a digitally signed section can corrupt the file or invalidate signatures, which kills trust with legal users immediately.

How it makes money

Per-seat annual license priced per user, with a free tier capped at files under 50MB to let individual users discover it before IT buys team licenses.