Every B2B SaaS eventually confronts the same unglamorous truth: before you can charge a single business customer, you need multi-tenancy and role-based access control. Many organizations sharing one deployment, each with its data walled off from the others, each with its own admins and members who can only touch what their role allows. It is the foundation nobody demos and everybody rebuilds — usually twice, because the first version leaked data between tenants. VBWD ships this layer as part of the core, so you start from the foundation instead of pouring it yourself.
VBWD is a self-hosted, source-available full-stack SDK: one Python backend core, a Vue/TypeScript web front end, and native iOS and Android SDKs — all driven from the same backend. Built into that core is RBAC plus multi-tenancy. In practice that means one deployment can host many customer organizations (tenants), each with isolated data, and access inside each tenant governed by roles rather than by ad-hoc if user.is_admin checks scattered through your code.
This matters because the core is intentionally agnostic. It does not assume you are building a booking app or a marketplace or a pharmacy. It gives you the tenancy and permission substrate, and your product logic sits on top of it as plugins. Capabilities toggle on and off without a restart, and plugins live in their own space — they never require forking the core. So the multi-tenant boundary is not something you bolt on later; it is already the shape of the system you are extending.
Say you are building a booking product — appointments, rooms, spaces, seats — and you sell it to salons, clinics, coworking spaces, and driving schools. Each of those businesses is a tenant. VBWD already has a booking capability (appointments, rooms, spaces, seats), so the vertical primitives exist; what the multi-tenant core adds is the ability to run all those businesses side by side on one deployment you control.
The same shape holds if your product is a marketplace instead. VBWD's marketplace capability is multi-vendor, and shop covers products, orders, stock, and shipping — so a marketplace-SaaS sold to many operator businesses maps onto the same tenant-per-customer model.
B2B customers always want their own integrations wired in: push a booking into their CRM, notify their Slack, sync their accounting. VBWD's core is event-driven with native signed webhooks. That means when something happens in a tenant — a booking is confirmed, an invoice is paid — the core emits an event you can route to that tenant's endpoint, signed so the receiver can verify it came from you.
The payoff is that per-tenant integration becomes configuration and subscription to events, not a code fork per customer. You do not maintain "the Riverside Clinic build." You maintain one product, and each tenant subscribes to the webhooks and integrations it needs.
For B2B, data sovereignty is frequently the deal-breaker or the deal-maker. Because VBWD is self-hosted, every tenant's data lives inside your infrastructure — your servers, your region, your compliance boundary. There is no third-party SaaS backend quietly holding your customers' customers. The core is GDPR-first, which matters when your tenants are themselves accountable to regulators and to their own clients.
Payments follow the same principle. VBWD supports many providers — Stripe, PayPal, PromptPay, Mercado Pago, Conekta, Toss, YooKassa, TrueMoney — and provider-agnostic, non-custodial crypto and stablecoin settlement where funds settle directly to the merchant's own wallet. Settlement does not detour through a platform intermediary. For a self-hosted B2B operator, that keeps both the data and the money inside your perimeter.
Here is what multi-tenancy and RBAC do not do for you. They do not design your tenant onboarding — how a new business signs up, gets provisioned, invites its team, and lands on sensible defaults is your flow to build. They do not write your vertical logic — the rules that make a clinic-booking product different from a coworking-desk product are yours. VBWD is a substrate, not magic. It removes the part every B2B SaaS rebuilds and gets subtly wrong; it does not remove the part that makes your product worth buying.
You also own the operations of self-hosting: deploying, upgrading, backing up, monitoring. That is the trade you make for sovereignty and control. For teams who need their customers' data to stay put — and who would otherwise burn a quarter reinventing tenancy and permissions — it is usually the right trade.
That VBWD is genuinely extensible is not a claim; it is visible in the vertical apps already built on it — a tarot app, a dice-market game (bdv), a pharmacy shop, and dataset publishing — all riding the same agnostic core you would build your B2B product on.
The public SDK is the place to read the actual seams: github.com/VBWD-platform/vbwd-sdk-public. If you are weighing a multi-tenant B2B build and want to talk through how tenancy, RBAC, and per-tenant billing would map onto your vertical, reach out via vbwd.cc/contact.
VBWD is source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year.