“Event-driven architecture” is one of those phrases engineers say with confidence and founders nod along to without quite buying anything. It sounds like an internal implementation detail — the kind of thing you delegate and forget. It isn’t. The way your platform is wired changes what you are able to build later, and by the time that constraint bites, it is expensive to undo. So it is worth understanding in plain terms, without the jargon.

Two ways to wire a system together

Imagine a customer completes a payment. A pile of things now needs to happen: activate their subscription, send a receipt, update the dashboard, notify the fulfilment system, maybe ping your CRM. There are two ways to make that happen.

The first way is direct wiring. The payment code calls the subscription code, which calls the email code, which calls analytics, and so on. Each piece knows about the next. It works — until it doesn’t. Every new thing you want to happen after a payment means editing the payment code. Six months in, that function is a tangle touching a dozen systems, and no one wants to change it because everything is connected to everything.

The second way is an event bus. The payment code does exactly one new thing: it announces, to no one in particular, “a payment was captured.” It doesn’t know or care who is listening. Elsewhere, independent pieces of the system have quietly said “when a payment is captured, wake me up” — one activates the subscription, one sends the receipt, one updates analytics. The announcement and the reactions are decoupled. The payment code never grows.

That announcement is an event. The thing that carries it is the bus. That is the whole idea. In VBWD it is quite literally one line of intent in the code:

event_bus.publish("payment.captured", { ... })

Everything that should happen next is a subscriber to that event, not a modification of the code that emitted it.

Why founders should care

The reason this is a business concern and not an engineering hobby is that the event bus is the spine every future capability hangs off. When state changes are announced as events, adding a new behaviour is additive — you write a new listener — rather than surgical, where you cut into working code and hope you didn’t nick an artery. That is the difference between “we can ship that this week” and “that touches the payment path, give us a quarter.”

It also makes the hard integration requests easy. “Notify our warehouse when an order ships.” “Sync new subscribers into our CRM.” “Trigger an n8n automation when a booking is made.” In a directly-wired system each is a bespoke project threaded through existing code. On an event bus they are all the same shape: something already announces the event; you add a listener that forwards it. The platform stops being a wall you build around and becomes a foundation you build on.

The honest caveat: event-driven design is not free of downsides. Because reactions are decoupled from the announcement, the flow of what-triggers-what is less obvious than a straight line of function calls — you trade a little immediate readability for a lot of long-term flexibility. For a system you intend to extend for years, that trade is worth making; for a throwaway prototype, maybe not. It is a deliberate choice, not a default virtue.

The payoff: webhooks and plugins fall out for free

Here is where the abstract idea turns into concrete capability. Once every meaningful state change is already an event on a bus, two of the most valuable platform features become almost automatic rather than separate builds.

Webhooks. VBWD attaches a single agnostic subscriber to the bus that turns any published event into a signed outbound HTTP delivery. Because it listens to everything and names nothing, “send my system an HTTP call when X happens” becomes a subscription in /admin/webhooks rather than a code change. Deliveries are enqueued synchronously and sent by a background worker out of band, HMAC-SHA256 signed with a per-subscription secret, and retried with backoff — a failing endpoint can never break the event that triggered it. The mechanics are laid out here: Webhooks in VBWD, Part 1: the event-driven engine.

Plugins. The same decoupling is why VBWD’s features — payments, subscriptions, catalogue, CMS, booking, chat — are plugins that switch on and off over an intentionally agnostic core, without a restart. A plugin participates by publishing and subscribing to events; it doesn’t reach into core internals. Which is why a subscription plugin’s subscription.activated event can reach your webhook, or your CRM, without anyone having wired those two things together on purpose. The bus did it.

It is written in tested Python and is self-hosted and source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay below the value of 6.7 BTC per year — so the bus, the deliveries and the secrets all live inside your own perimeter, and extending it is a small, safe change rather than a vendor ticket.

The point for a founder is not the plumbing. It is that an event-driven core quietly widens the set of things you can say yes to later — new integrations, new automations, new features — without rebuilding what you already have.

If this maps to a conversation happening inside your own organisation, the useful next step is specific rather than generic: see your own workload on modern, self-hosted infrastructure. Request an enterprise installation and bring the numbers you’re trying to improve.