Every platform team eventually faces the same fork in the road. You need a capability the base system doesn't ship — a new payment provider, a booking flow, a metered-billing model — and the only obvious way to add it is to reach into the core and change it. That single decision quietly mortgages your future. Once you've edited the core, every upstream upgrade becomes a merge conflict, every security patch a risky rebase, and your "customized platform" slowly drifts into an unmaintainable fork nobody wants to touch. VBWD was designed to make that fork unnecessary.
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 that single backend. The defining architectural choice is that the core is deliberately agnostic. It knows about generic concepts — users, roles, events, payments, content — but it does not hard-code your business. It doesn't assume you're running a shop, a booking system, or a subscription service. Those are capabilities, and capabilities live in plugins.
This inversion matters. In most stacks the application is the core, and extensions bolt on at the edges. In VBWD the core is the substrate, and everything opinionated — including entire product verticals — sits in plugin space above it. The core exposes seams: an event bus, provider registries, permission and dependency-injection points. Plugins plug into those seams. The core never reaches up into a plugin, and a well-behaved plugin never forks the core to do its job.
Because capabilities are plugins rather than baked-in code paths, they can be turned on and off at runtime. Enabling or disabling a plugin is a state change the platform applies live — no redeploy, no restart, no downtime window. That's a practical superpower for a small team: you can bring a capability online in production, watch it, and turn it back off just as cleanly if something looks wrong. The blast radius of trying something is small, and reversibility is built in rather than bolted on.
It also changes how the same codebase serves different customers. One tenant runs with the shop and subscription plugins active; another runs booking and token-payment; a third adds chat and an LLM layer. The core underneath is identical. You're composing a product from capabilities, not maintaining a matrix of forks.
Each plugin owns its own directory, its own models and migrations, its own routes and admin surfaces, its own configuration, and its own tests. It declares what it depends on and registers itself through the core's published extension points. Conceptually it looks like this:
class MyPlugin(BasePlugin):
metadata = PluginMetadata(
name="my-plugin",
version="1.0.0",
dependencies=["subscription"], # depend on peers, never edit them
)
def on_enable(self):
# register routes, DI providers, payment adapters,
# and subscribe to core events — all through seams
self.container.register(MyRepository)
self.bus.subscribe("invoice.paid", self.grant_access)
def on_disable(self):
# clean teardown so the capability toggles off cleanly
...
The important part isn't the exact syntax — it's the discipline it enforces. Your feature code stays in your plugin's space. Upgrades to the core arrive as upgrades, not as a three-way merge against your edits. Because the boundary is real, the upgrade path stays clean for everyone at once.
This isn't an aspiration; it's how VBWD ships. The capabilities you'd expect a mature platform to have are themselves plugins living on the agnostic core: booking (appointments, rooms, spaces, seats), marketplace (multi-vendor), shop (products, orders, stock, shipping), subscription (tarif plans, add-ons, checkout), token_payment (a token/credit economy and metered billing), dataset (selling digital goods and data), mcp (MCP-native, agent-callable endpoints), a chat module with an LLM connection layer, bot_telegram, cms and cms_ai for content, office for encrypted documents, plus discount, referral, and withdraw (payouts). RBAC and multi-tenancy come standard, and the core is event-driven with native signed webhooks.
Payments show the pattern especially clearly. VBWD carries many providers — Stripe, PayPal, PromptPay, Mercado Pago, Conekta, Toss, YooKassa, TrueMoney — behind a provider-agnostic layer, and it supports non-custodial crypto and stablecoin settlement where funds land directly in the merchant's own wallet. Adding another provider is adding an adapter, not surgery on a billing engine.
The strongest evidence that the seams hold is that entire products have been built on VBWD without forking it. There's a tarot app, a dice-market game called bdv, a pharmacy shop (shop_pharma) built on top of the shop capability, and dataset publishing. These aren't demos of a theoretical extension point — they're differentiated applications, each with its own domain logic, all riding the same unmodified core. If a tarot reading engine and a pharmacy checkout can coexist as plugins on one substrate, your vertical almost certainly can too.
A clear plugin boundary is exactly the kind of guardrail that lets a two-person team, or an AI coding agent, add capabilities without fear. The rules are legible: don't touch the core, live in your own directory, extend only through the published seams, declare your dependencies. That constraint is what makes automated and semi-automated development tractable — the agent has a contained space to work in and a bright line it must not cross. Combined with runtime toggling, a mistake is contained and reversible instead of catastrophic. And with the mcp plugin, the platform's own capabilities become agent-callable, which closes the loop nicely: agents can operate the platform through the same disciplined surface they'd use to extend it.
None of this is magic, and it's important to say so plainly. VBWD is a substrate, not a shortcut around building a real product. The plugin system removes the forking tax; it does not remove the work. You still design your plugin, write its domain logic, test it, and maintain it as the core evolves — peer plugins you depend on can change, and you own keeping up. And because VBWD is self-hosted, you own the operations too: deployment, upgrades, backups, monitoring, and security are yours. What you get in exchange is a clean, upgradeable foundation and a boundary that keeps your differentiated work from entangling with the platform underneath. That's a very good trade, but it's a trade, not a free lunch.
If that architecture fits how you want to build, the public SDK is the place to start: github.com/VBWD-platform/vbwd-sdk-public. If you'd rather talk through whether a plugin or a full vertical is the right shape for your product, reach out at 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.