Version 1.0 can be out in an hour and requires one page to register webhooks, one place to store outgoing event data (which can be in anything -- a SQL database with a column representing a JSON bag-of-serialized-attributes will work fine), and a cron job. The minimum implementation is not difficult engineering.
A lot about what Stripe does right is in the ancillary bits about consuming their webhooks:
1) Spend a lot of time thinking about what your retry policy is. Some service providers (including ones which I like) will do one callback and then not retry. This is often suboptimal for consumers. I personally like "retrying with expotential decay", which is a nice balance between "You get your webhook really, really quickly if a gremlin just happened to eat the first one" and "If your servers are experiencing hard downtime, we won't add to the problem by pinging the heck out of you."
2) There is no SaaS or open source option for "Have great documentation, at once both comprehensive and easy to consume for the goal-oriented developer."
3) There are a lot of failure modes for webhook systems, some of which you'll only discover when operating them. Transient network problems between your application and the consumer's. "Failure to agree on reality" between different moving parts of your application. Adding webhooks to the outgoing queue in a non-idempotent fashion, which seems to be one of the great Let Me Tell You About This One Timee stories in systems engineering. Timing issues with consumers receiving webhooks in an order other than that which they would logically expect, which might not be your problem but good luck convincing a customer of that.
You'll want to have instrumentation and monitoring up that wazoo, so you can resolve these little usage niggles. This boring, iterative execution on the base feature is approximately 99% of why really well-executed APIs (like Stripe or Twilio or whomever) are really fun to work with and, well, why there exist some APIs which are less fun to work with.
