But we're solving different problems. You're working with local files you already have. I'm targeting apps where images are already living in S3/R2 somewhere — user uploads a product photo, SaaS needs to watermark it before displaying, that kind of thing.
In those cases the alternative isn't "run FFMPEG locally" — it's download from S3 to your server, run Sharp or FFMPEG, upload back to S3, manage worker queues when traffic spikes, handle retries when things fail. Basically all the plumbing around the actual watermarking.
For your workflow this API makes zero sense. Local batch processing with FFMPEG is objectively better. No argument there. But if you're building a SaaS where users are uploading images and you need to watermark them server-side, would you rather write all that infrastructure or pay a penny per image and ship your actual product features faster? That's the bet I'm making.
Might be totally wrong! But "pay someone to handle the boring infrastructure" has worked for Stripe, Twilio, AWS Lambda, etc. Same play here but for image processing.