Watermark API – $0.01/image, 10x cheaper than Cloudinary(api-production-caa8.up.railway.app)
4 pointsby lembergs4 hours ago4 comments
  • lembergs34 minutes ago
    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.

  • VladVladikoffan hour ago
    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.
    • lembergsan hour ago
      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.

  • cr125rideran hour ago
    I even pay through an API? That’s interesting. I was wondering how difficult it was to setup payments vs. the actual service.
  • lembergs4 hours ago
    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

    • romanderyo3 hours ago
      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.
      • lembergs2 hours ago
        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.

        • benburlesonan hour ago
          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.

          • lembergsan hour ago
            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 :))"