Anyone built a webhook delivery system before?
Hey Indie Hackers,
Has anyone here built a system to produce webhook events (that your customers can consume)? From my experience building a delivery system can take anywhere from a few weeks to a few months and every startup that needs one today is building it in house. Moreover, companies need similar features across the board such as logs, retries, analytics, rate limiting, idempotency, security signatures, etc. I'm working on a SaaS solution to provide webhook delivery as a service and I'm curious of anyone here has seen the need for such a product or would like to be beta customers.
Thank you!
Trending on Indie Hackers
I don't see how all of that fits into one product. Implementing a webhook system is no rocket science. The last one I built has auth, retries and scales to big numbers. It was built in hours - not weeks or even months. Or I must be missing something.
TBH it's nothing I would want to outsource.
I agree. Webhooks are just glorified POST requests and are quite easy to implement. The friction and risk of implementing a webhook system would be less than that of adopting a third-party service IMHO.
I would do a lot of customer development (that is, find people who are willing to pay you to have access ASAP for a slightly discounted rate) because this doesn't sound like a real problem to me. I've never heard anyone express this as a pain point.
It's not at all clear to me why I would be able to notify your service to send a webhook to my user, but not be able to just send that webhook from a worker job inside of the app itself.
You have to understand that the cost of introducing a 3rd party dependency to handle something like this is huge. Managing separate logs, integrating with your analytics, all while knowing that your service could go down or like all startups, that you might not exist in two years... it's really hard to imagine going to my CTO with this as a proposition. It's got almost nothing to do with money.
You owe it to yourself to find ten people willing to pay up front before putting significant development effort into this.
Very well said.
True. It strikes me that maybe webhooks are one of those things that people take as a core part of their business, so they're fine with implementing it themselves.
Same thing I wondered. I think that, if analytics etc are really a pain, what would be best would be a package I can add to my app or install and run to handle all of that. But then, there are open-source packages for that (I think).
Then again, we could both be wrong. Who knows, there might be folks out there ready to pay for such a service.😄
While it’s possible that I’m just spoiled as a Rails developer, I have a strong suspicion that this just isn’t hard to do with most frameworks. There’s no need for an extra package; in fact, that would be more complex. Just create a job that calls an HTTP request. You get to decide on logging, retry falloff etc.
As for the concept of a sleeper customer base, that’s just not a thing. Selling anything is hard.
I’m not wrong because the sum total of my advice is “do customer validation before building this”. If the OP can’t find ten people who are urgently willing to pay to be the first in the door, there’s no market opportunity here. Best to know what’s up going in.