Launched: webhook scheduler after rage-quitting per-request pricing
I kept hitting the same wall: side project needs to fire an HTTP webhook at
an exact time (trial expiry, deferred charge, follow-up ping). Serverless
times out before the delay lands. A real broker is a weekend of YAML for one
HTTP call. QStash's flat plan starts at ~$180/mo — overkill for an indie project.
So I built SendItWhenever.
What it does:
- schedule({ url, fireAt, payload }) → fires on time, HMAC-signed
- Payloads encrypted at rest (AES-256-GCM), decrypted only at fire time
- Automatic retries, dead-letter queue, searchable delivery log
- Early Firing: measures target RTT and fires slightly ahead (best-effort)
- Node + Python SDKs published; live playground on the landing page
Pricing I landed on after a lot of back-and-forth:
Free (2k sends/month) to start, no card.
Indie plan: 1 month free, then $15/mo locked for life — for the first 50 founders.
After the founding window closes, it's $19/mo. No per-request billing ever.
Would genuinely love feedback on the pricing and the dashboard.
https://www.sendit-whenever.com/?utm_source=indiehackers&utm_medium=social&utm_campaign=launch
What I'd be paying attention to is whether users are escaping per-request pricing or avoiding operational complexity.
Those can look like the same motivation early on.
Someone frustrated by pricing may still tolerate complexity, while someone frustrated by complexity may happily pay more. The stronger signal could end up shaping the business more than the scheduling problem itself.
That's a sharper cut than I've been making — I've been treating both groups as "webhook scheduler pain" without separating the underlying driver.
My hunch is that the complexity-avoiders are the better long-term signal. Someone who didn't want to stand up Redis + BullMQ + DLQ + retry monitoring isn't suddenly going to want to do it at scale — that pain compounds. Per-request pricing frustration is real, but more negotiable. People rationalise costs once something works.
What I'll watch for early: how they describe the problem at signup. "I didn't want to build this" reads very differently from "Upstash got expensive." The first person is paying for time and relief; the second is paying to avoid a line item and might leave the moment the math shifts.
The thing that worries me slightly is that the pricing-escape crowd will be louder at launch because the comparison is concrete. The complexity signal tends to surface quieter and later — once someone realises they haven't touched the scheduler in six months and it just kept running.
You've made me want to ask explicitly which one drove the signup, rather than inferring it. Appreciate the framing.
Glad it was useful.
One part of your reply made me think we're probably looking at a slightly different decision than it first appears.
Happy to explain what I mean if you're open to it.
What's the best email to reach you on?
Yes, genuinely curious — please do explain.
soft37@working37 .net
Sent it across.