- 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.
Thanks for the reality check :)
On to the next one.
- There is a market for your idea: (see imgproxy)
- I don’t get it? Wouldn’t figuring out a simple FFMPEG command to watermark an image (or video) take less time than integrating with an API to do it? Plus if you had to do a lot of images it would be much faster to work locally than having to ship the images remotely somewhere. -someone who does this a lot, specifically for videos.
- 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.
- non watermarked content can reside on an s3 bucket or http path, referenced by squid as the origin server, which is Icap Aware , and you can run any command on the content;
Antivirus, ffmpeg to watermark a doc … or indeed a third party API..
it’s most commonly used to do antivirus on a transparent proxy and block infected file downloads but you can run any command you want.
Including watermarking everything with a company logo , “confidential “ , or a unique ID of the requestor.
or making subtle alterations to md5sums , metadata etc in confidential documents or for each requestor to track down leaks and sharing.
Nakivo does something kind of like that with product downloads (executables) to manipulate them and require a specific file name to install that goes back to the info you furnished for a demo.
All sorts of use cases for these alterations, I wouldn’t necessarily abandon an idea that’s interesting or challenging to you and id encourage you to spend a little more time on whether youve considered them all and whether they’re marketable
Then if it’s not interesting as a standalone product it might be something you can bake into a paid CMS plugin (Wordpress, Xenforo, etc) for people who are savvy enough to deploy those kinds of products but maybe not go this far with it.
My bread and butter , I guess.. isn’t something mass marketable , but it’s something i enjoy, am wired for, and never really get burned out or bored of.
- I even pay through an API? That’s interesting. I was wondering how difficult it was to setup payments vs. the actual service.
- 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.
Try it: https://api-production-caa8.up.railway.app/docs ```
## Additional Context for Discussion
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
- Honest question: does integrating with this API require more code than just using Sharp directly? Especially now that anyone can ask an AI to write the watermarking script for them.
- 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 think these types of projects are really great for developers to exercise their end-to-end skills -- developing all pieces of the product. Kudos for launching it!
As someone who's done this before, the value is all in that experience and finding those gaps that you didn't know existed.
One important gap I originally didn't know about was needing a market for my product idea. I thought just because I had a clever idea that it would sell! Turns out that's not the case most of the time.
And in this case, I don't think there's a market for no-code solutions that simultaneously require HTTP API integration (that's not no-code, that's low-code), when there is a really simple low-code solution that doesn't require a network round-trip.
Again, kudos on completing the exercise of releasing something! It's a step most developers don't take, and absolutely worth the experience no matter where it goes.
- uuugh :))
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 :))"
4 points by lembergs 4 hours ago | 11 comments