Product build
aiPDF Engine
One sentence in, the cleaned file out
Most PDF tools hand you a wall of buttons: split, merge, rotate, OCR, compress, repair. This one takes a sentence. You say "clean up this scanned packet," and a planner works out which operations to run and in what order, then hands each job to a worker built for exactly that.
The problem
Real document work is a chain of boring steps, and the order matters. Doing it by hand means knowing which button to press, and when. Doing it at scale adds a second problem: a job cannot fall over halfway through a long scanned filing and leave you with a mess and no way to tell how far it got.
The build
A FastAPI router takes the upload and the request. The actual work goes onto a queue, so nothing blocks while a big file grinds, and a job that fails retries on its own instead of taking everything down. If it keeps failing, it lands in a dead-letter queue where I can see it rather than disappearing.
Three workers each own one kind of job. One splits, merges, and rotates. One pulls out the text and runs OCR on the pages that are just pictures of text. One compresses and repairs. A table tracks every job's state and each user's quota. On top sits the planner: it reads the plain-English request and turns it into the chain of workers that satisfies it. The whole stack deploys from one infrastructure file and runs on my laptop against a local AWS stand-in before it ever touches the cloud.
The outcome
A request in plain English became a sequence of small, deterministic, retryable steps, each handled by the worker that does it best. The PDF operations were the simple part. The work went into the planner choosing the right chain, and the queue keeping a long job alive past the page where something breaks.