You already answered your question.

1. You spent hours building a small Go tool, assuming your hour is worth at least a $100 (certainly more) and say you spent 5 hours, that's $500. 2. You deployed it on a VM, that's $5 a month 3. You need to keep it updated and manage it, so let's say you spend 1 hour a month. That's a $100 a month.

So right now you spent $500 upfront, and $105 a month to keep it going, and that's assuming 1 hour a month which is crazy low.

You can replace that entire cost with a static Y x 0.001 + what ever up front cost to convert the system to use Svix, which can be factored into the system cost. I have 50,000 users, each user has 1 webhook I need 50,000 x average number of messages a month. Just add that on top of the system monthly cost.

It's a lot easier to manage from a business/accounting point of view a SAAS then your own homebrew.

So instead you should spend 5 hours reading about some service that might not exist in a year and doing integration work with it?

It's not like you're going to integrate some service into your app in 0 hours.

It's also not like you won't have to spend some time maintaining your integration either.

IMO, a "killer feature" for a business is not /maybe/ saving $100 a month under low usage, and /maybe/ costing you $1k+ under high usage...

Five hours is a gross underestimate for the time it takes to build a robust and scalable webhooks delivery system, and even that is just for the delivery system itself. You also need to build the UI for your users, libraries for verifying signatures and etc.

All of this assumes you know what you are doing and can just write the code. It doesn't even take into account the research you need to do to make sure you cover all of the security (and other) consideration that GP seemed to have already known about and took care of.

Right! Vendor driven churn is a costly burden. I'm going to post more about the tool later.

> It's a lot easier to manage from a business/accounting point of view a SAAS then your own homebrew.

Hmm I would have to disagree here. This is something that most platform teams could build, deploy and forget about. Setting up an account, getting procurement to pay for it, not being able to see why it’s down etc just seems like a lot more hassle.

For a lot of services like this I think the value prop is not monetary cost but more "this is no longer your responsibility". Since you already have a custom-built solution that is stable & operating efficiently, switching doesn't sound worth it to you. For a team that's looking to add webhook functionality for the first time, not needing to go through the implementation work themselves or need to deal with any maintenance longer-term could sound very appealing. I think it's akin to the rise of interest in user-management-as-a-service products, etc.

I'm not, to be clear, expressing an opinion that the business will be successful with that strategy or that I think it's a good trend. On the contrary, this overall trend of feature-x-as-a-service products depresses me a bit. We've gone from the old days when you had to write pretty much everything yourself (which sucked), to the days when there were a ton of feature-x-as-library choices (which was way better but led to complaints of web programming becoming a chore of just bolting libraries together), to the current trend of feature-x-as-service products.

It's a logical evolution in some ways - similar to libraries over roll-your-own, it reduces your own set of responsibilities. But it also reduces your ability to learn (e.g. from reading source) or grow beyond the provided service (much harder to swap out providers or roll-your-own when the current solution is a third party black box). It also feels depressing in that we've gone from a thriving ecosystem of software based on open source to a much more capitalism-first ecosystem of "this could be a library but then how would I make money off of it". (I realize open source funding & maintainer compensation/sanity is its own set of problems. I just wish we could work on those issues without turning everything into a product.)

Yup. My teammates joke that the best problem to have is “not my problem”.

This might be a simple service, but this is one less thing to worry about

Yes, but there is no worth about any compliance regarding data protection that includes the webhooks. Also company is based in the US so that causes Privacy Shield issues.

Not easy to use this service when you need follow all kinds of regulation and the GDPR

All of our servers are in Europe, and we are soon going to tackle getting compliance certifications (as users have been asking for this).

Do you find that unnecessarily adds latency for webhook event ingestion from the US? Seems like that would add a point of failure that makes me even more nervous here -- instead of a quick request to us-east-2, I have to send data across the pond.

Yeah, this is less than optimal, and that's why we are working on adding zones. It just made sense to start with Europe while we are in just one (due to compliance). We also plan on having our API endpoints on many different zones so that for our customers API calls are immediate.

That's what I was thinking. Having ingress/egress processes in specific zones will definitely help here, while keeping your datastores in EU without any issues of data loss at the edge.

For example, ingress for receiving events in a US zone, those are asynchronously pushed to the EU datastore, and then egress for delivering the events are again in the US zone, transparently pulling data from the EU.

Not sure on your architecture, but just spit balling how you could keep data stored in the EU while temporarily "processing" that data in the US to keep latency low where it matters.

Yeah, thanks a lot for the feedback!

We are going to prioritize this task based on your feedback. It's definitely a concern. We don't even need to store the data in the EU if our users don't want/need it. We can even let them choose zones themselves for ingress - as in many (most?) cases, they would only be using one zone themselves.

Doesn't matter the terms suggest the company is based in Delaware:

This agreement will be governed by the laws of the Delaware, USA. The courts of Delaware have exclusive jurisdiction to settle any dispute arising out of or in connection with this agreement

IANAL, though this is for disputes. Not for compliance with international laws which we can do anyway. The question is: can a US company with servers solely in Europe can comply with the European legislations. Based on my understanding the answer is yes, though I'll double check with the experts. :)

I'd say that the main complexity comes from exposing the logs/analytics to your end-users. I am hoping Svix will help companies implement Webhooks as well as companies like Stripe do.