Appreciate everyone's honest feedback here. The consensus is clear:
watermarking isn't painful enough to justify an API, especially when
Sharp + ChatGPT solves it in 10 minutes, and the no-code market I
described doesn't actually want API integration.
This was a 7-hour validation experiment and it worked — I learned
the idea doesn't have product-market fit. Killing it now rather than
spending weeks marketing something nobody wants.
Thank you for eye opener :D
You're right that the no-code angle has a gap — if someone's using Zapier they probably want a simple action that doesn't require API knowledge at all.
Genuinely appreciate you pushing on this. I guess I should kill it and build something else. Way more valuable than "this project should be cool :))"
You're 100% right for your use case. FFMPEG locally will always be faster than shipping images over the network.
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.
Fair. If you’re a dev watermarking a few images, Sharp directly is the obvious choice.
This exists for cases where Sharp is annoying, not hard:
- offloading CPU-heavy image work from your servers
- batch jobs (hundreds of images → one API call + ZIP)
- no-code / Zapier / Make users
Not targeting solo devs who like writing image pipelines. More for agencies, no-code users, and apps that want “watermarking as a service.”
Genuinely curious if “Sharp as a Service” is a clearer framing — or if this just isn’t painful enough to justify an API.
I built a dead-simple watermarking API because existing solutions
(Cloudinary, imgix) are overkill and expensive for developers who
just need to slap a logo on images.
- $0.01/image or $19/mo unlimited
- 50 free images to test
- 5-minute integration
- API-first, no dashboard bloat
Built in 7 hours. Looking for feedback from developers who've
struggled with this problem.
If the post gains traction, be prepared to discuss:
### Technical Details
- Built with Node.js, Express, Sharp for image processing
- Uses Cloudflare R2 for storage (S3-compatible, cheaper than S3)
- PostgreSQL for tracking usage and credits
- Stripe for payments
- Deployed on Railway.app
### Why This Exists
- Cloudinary charges $0.10-0.15 per image for watermarking
- imgix starts at $199/month for basic features
- Many developers just need simple batch watermarking
- Existing solutions require complex dashboards and setup
### Performance
- Watermarks 1,000 images in under 2 minutes
- Batch processing up to 100 images at once
- Returns ZIP files for batch downloads
- All processing happens server-side
### Pricing Comparison
- *Our API:* $0.01/image or $19/month for 2,500 images
- *Cloudinary:* $0.10-0.15/image (10-15x more expensive)
- *imgix:* $199/month minimum (10x more expensive for similar volume)
### Use Cases
- E-commerce sites watermarking product photos
- Photographers adding logos to portfolios
- Social media managers branding images
- Developers building apps that need image watermarking
This was a 7-hour validation experiment and it worked — I learned the idea doesn't have product-market fit. Killing it now rather than spending weeks marketing something nobody wants.
Thanks for the reality check :)
On to the next one.