Nobody sets out to build an integration company. You set out to build a product that does one thing well — invoicing, booking, a catalogue, a support desk. Then the first serious customer arrives and asks the question that reshapes your roadmap: “Can it talk to our systems?” Their CRM. Their ERP. Their warehouse software. Their data lake. Their finance team’s reconciliation spreadsheet that, somehow, the whole company depends on.

From that moment on, a large share of your engineering budget quietly becomes integration work. Not features your users see, but plumbing between your world and everyone else’s. This is the unglamorous truth of the SaaS business: every successful platform eventually becomes an integration company, whether it planned to or not.

Integration isn’t a feature — it’s the surface area of your product

The reason this sneaks up on people is that integration doesn’t look like one big project. It looks like a hundred small ones. A customer needs a Slack ping when a payment fails. Another needs their data warehouse updated when a subscription renews. A third wants their fulfilment system triggered the instant an order is placed. Each request is reasonable. Each one, handled ad hoc, becomes a bespoke endpoint, a cron job, a polling script, a fragile bit of glue that someone has to maintain forever.

Do this enough times and you’ve accidentally built a distributed system with no coherent design — a dozen one-off pipes, each with its own auth, its own retry logic (or lack of it), its own way of failing silently at 3am. The platforms that win the integration game don’t win by writing more glue. They win by making the glue unnecessary: by exposing their internal events as a clean, signed, self-service stream other systems can subscribe to.

That’s the insight worth internalising early: webhooks are the product. Not a nice-to-have on the settings page — the actual mechanism by which your software becomes a citizen of a customer’s wider stack instead of an island they have to bridge to by hand.

Why so many platforms make this hard

Most SaaS backends weren’t designed event-first. State changes happen inside a request handler, deep in the code, and nothing outside that function ever learns they occurred. So when a customer asks to be notified when X happens, an engineer has to go find every place X can happen, bolt on an HTTP call, add signing, add retries, add a dead-letter path, and pray they found all the code paths. It’s error-prone, it’s slow, and it means every new integration is a new engineering ticket. The result is the familiar tax: integrations that lag months behind demand, and a “webhooks” feature that supports six event types because that’s all anyone had time to wire up.

The fix isn’t more discipline about bolting on HTTP calls. It’s to make emitting an event the default way state changes are recorded — and to relay those events to the outside world through one agnostic mechanism, once, correctly.

How VBWD resolves it: an event-driven core with native, signed webhooks

This is the design decision at the centre of VBWD. The core is genuinely event-driven: every meaningful state change publishes an event on an in-process bus — event_bus.publish("subscription.activated", {…}), a captured payment, a cancelled booking, a stock movement. A single wildcard subscriber listens to everything and relays it to the outbound webhook layer. That relay is deliberately agnostic: it never names a plugin, never special-cases an event type. It forwards whatever is published.

The practical consequence is that adding an integration stops being a project. Deliveries are HMAC-SHA256 signed over the exact JSON body with a per-subscription secret, sent with X-VBWD-Signature, X-VBWD-Event, X-VBWD-Delivery-Id and X-VBWD-Timestamp headers, so the receiver can verify authenticity by recomputing the HMAC over the raw body. You don’t hand-roll security you’ll get subtly wrong. And because the relay carries whatever is published, an event added by a plugin next month automatically reaches any subscriber listening on ["*"] — no core change required.

Reliability is designed in, not bolted on. Emission and delivery are decoupled: publishing writes a pending delivery row synchronously, and a background scheduler performs the HTTP POST out of band. A webhook failure never breaks event emission — your business logic doesn’t stall because someone’s endpoint is down. Retries use capped exponential backoff, every attempt is persisted, and a subscription that keeps failing auto-disables and surfaces as failed — visible, not silently rotting.

Two honest caveats. First, delivery is near-real-time, not instant — the scheduler dispatches on a short cycle, which is the right trade for durability but worth knowing if you expect sub-second reactions. Second, VBWD is younger than the twenty-year-old incumbents; it trades some accumulated edge-case maturity for a cleaner, event-first architecture. For teams who’ll spend the next few years being asked to integrate with everything, that’s usually the better trade — but not always, and you should decide honestly.

Because it’s written in tested Python and source-available under BSL 1.1 (free while annual VBWD-attributable sales stay under the value of 6.7 BTC a year), the bus, the deliveries and the signing secrets all live inside your perimeter, and extending the system — a new event, a new integration — is a small, safe change rather than a platform negotiation. The mechanics of that engine are worth reading in full: see Webhooks in VBWD, Part 1: the event-driven engine.

If your roadmap is quietly turning into an integration backlog — and it probably is — the useful next step is specific rather than generic: see your own events flowing on infrastructure you control. Request an enterprise installation and bring the integrations you’re tired of hand-building.