⚡ VBWD
A sales platform for the digital world — SaaS subscriptions, CMS, shop, booking and a token economy on one self-hosted backend, two Vue front-ends and one plugin contract.
An enterprise plugin core — build once, ship every product your market needs
Agencies, platforms and product teams hit the same wall: every new client, vertical or pricing experiment becomes another fork to maintain — or a tangle of feature flags nobody trusts. VBWD takes a different bet. Every capability is a plugin — payments, subscriptions, CMS, booking, shop, AI chat, software distribution — each an isolated module with its own repo, tests and lifecycle, around one hardened, vocabulary-free core. You compose the product instead of forking the platform.
Compose the exact product — per client, per tenant
Turn a capability on or off from the admin and the whole stack reshapes: its API routes, admin menus, settings panels, user-facing pages, database tables and webhooks appear or disappear cleanly — no rebuild, no redeploy. One client gets bookings and a storefront; the next gets AI chat and software licensing. Same core, different surface, zero forks.
One codebase, a hundred deployments
Plugins live in their own vbwd-plugin-* repos with
their own CI, versioning and migrations — so independent teams
ship in parallel without touching the core, and onboarding a
client is a config diff, not a release. The core stays small and
stable while the catalogue grows around it, and a tenant only
loads the plugins it enables — footprint scales with need, not
with the size of the platform.
Safe to run across every tenant
Each plugin carries a JSON-schema settings panel, RBAC-gated routes and a single source of truth for its state — the backend is the only writer, so there is no per-browser drift across a fleet. The core is provably plugin-agnostic (an AST test fails the build if core so much as imports a plugin), every module ships its own test suite, and the lifecycle has an explicit error state for safe failure. Flexibility without the maintenance tax.
A plugin is not a config flag
It is a coordinated trio of contributions. A single plugin entry can register code into all three runtimes at once — each runtime exposes a typed surface so plugins extend it without forks, monkey-patching, or "please rebuild the core" tickets.
API endpoints, data models + migrations, event handlers, own domain events, line-item / shipping handlers.
Menu items, full-page views, dashboard widgets, JSON-schema settings panels, permission gates, translations.
addRoute, createStore, addComponent, addTranslations — routes, Pinia stores, widgets, locales.
Safe by construction
DISCOVERED → REGISTERED → INITIALIZED → ENABLED ↔ DISABLED
with an ERROR state for safe failure. Persistent
across restarts via the plugin_config table; the
backend is the only writer. Toggle a plugin and every route,
menu item, table and webhook it owns appears or disappears
cleanly — no rebuild, no redeploy.
Demo plugins that prove the platform
Each one a complete feature; each one optional; each one composable.
mainchatPublic, pre-account chat — FAQ, support intake, lead capture, in-thread peer-to-peer token transfer. Lands in the same admin inbox as authenticated chats.
bookingCalendly-grade booking on your data, auth and billing. Resources + slots, inventory holds, cancel/reschedule policy, per-plan quotas.
shopDigital-goods + software store on the same checkout as subscriptions. Catalog, cart, orders, RMA, license keys, signed downloadables.
llm-chatReference demo: internal token wallet metering + a provider-agnostic external-API connector (OpenAI / Anthropic / Mistral / self-hosted).
tarotReference demo for the subscription engine: tiered plans, monthly grants, plan-gated features — all configured in admin, nothing hardcoded.
discount + checkoutTwo halves that meet at the cart: server-validated codes with stacking rules + a multi-provider, country-aware, idempotent checkout.
Every row is a real plugin — toggle it in
/admin/settings/plugins. Plugins live in their own
vbwd-plugin-* repos. Browse the repos →