The moment someone in a document-heavy operation — legal, accounting, insurance, medical records — needs to convert 50 PDFs or a 2GB mailbox export and their desktop tool freezes or grinds for two hours, they realise nobody has properly solved this for them. They're not a developer, so they can't spin up a cloud pipeline themselves. They're also not the IT budget holder, so they can't get a server provisioned quickly. They're stuck waiting, or worse, babysitting a process that crashes at file 47.

The gap persists because desktop conversion vendors make money selling perpetual licenses, and moving processing to the cloud would require them to rebuild their billing model and absorb server costs — an uncomfortable structural shift that incumbents have no incentive to make. The buyer (the person who purchased the license) is usually IT, but the person suffering through the slow conversion is an office worker who just quietly waits. Nobody files a strong enough complaint to force a re-architecture.

What existing tools get wrong for this case specifically: they process files sequentially on the local machine, so the fifth file in a batch waits for the first four to finish. Users describe exactly this — 'sometimes the conversion time is longer than it should be with more than 5 files' and 'doing it one by one is very time-consuming.' Parallelising the queue on a remote worker pool eliminates both the crash risk (no local memory exhaustion) and the serial bottleneck.

This is a business and not a feature because the need recurs every week for anyone processing incoming documents at volume. A firm converting client-submitted PDFs daily can't afford to have a staff member's machine locked up for an hour — the cost is real and measurable. The service charges per minute of processing time or per gigabyte processed, which means revenue scales directly with the customer's actual usage and grows as their document volume grows.

What to build

Build a web-based queue that accepts bulk file uploads (PDF, MBOX, video, audio), distributes each file to a parallel cloud worker for conversion, and delivers a downloadable ZIP when all jobs finish — with no file size cap and no serial waiting.

Where to start

Start with MBOX-to-PST conversion specifically, because it's a well-defined migration task with a clear triggering event (email platform switch), the files are always large, and the desktop tools fail most visibly here — giving you a concrete before/after story to sell.

The hard part

Pricing the processing cost precisely enough that you don't lose margin on large video files or 10GB mailbox exports, which can consume twenty times the compute of a simple PDF batch — getting the per-unit economics right before you've seen real usage patterns is genuinely hard.

How it makes money

Usage-based billing per gigabyte of input file processed, with a free tier capped at 500MB per month to drive word-of-mouth; enterprise accounts pay a monthly minimum against a usage allowance.

See the evidence. The complaints behind this idea, the products they came from, and similar ideas in File Converter.

More ideas in File Converter