Everyone can wrap a chat box around an LLM. The hard part — the part that actually makes a business — is everything around the model: accounts, isolated workspaces, plans, per-message metering, invoices, a Telegram surface, an API other tools can call. That productization layer is exactly what VBWD gives you, so you can ship an AI-assistant SaaS in weeks instead of rebuilding billing and multi-tenancy from scratch.

Who buys it? Agencies that want a branded "AI helper" for their clients, SaaS founders adding a domain-expert assistant (legal intake, support triage, tutoring, internal ops), and consultants who have valuable prompts and data but no platform to sell access to. The value isn't the raw model — it's the packaged, metered, multi-tenant product wrapped around it.

What VBWD gives you out of the box

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. The core is agnostic and everything ships as plugins that toggle on and off at runtime, without a restart. For an assistant SaaS you compose a specific set of them:

• chat + LLM modules (meinchat + LLM connection) — the conversational surface and the connection layer that talks to your model provider. This is the assistant your customers actually interact with.
• token_payment — a token/credit economy with metered billing. This is how you charge per message or per query: each interaction burns credits, and customers top up or draw from an allowance.
• subscription — tarif plans, subscriptions, add-ons, and checkout, so you can sell monthly tiers alongside (or instead of) pure credits.
• RBAC + multi-tenant — every customer gets an isolated workspace with its own users, roles, and data. One deployment, many tenants, no cross-tenant leakage.
• bot_telegram — ship the same assistant into Telegram, so customers reach it where they already are, not only through your web app.
• cms / cms_ai — the marketing site, docs, onboarding content, and landing pages, managed in the same platform.
• mcp — makes your product itself agent-callable over MCP, so other agents and tools can drive your assistant programmatically. Your SaaS becomes a capability other systems can compose.

Underneath all of that sits an event-driven core with native signed webhooks, a real payment layer (Stripe, PayPal, and more), and provider-agnostic, non-custodial crypto/stablecoin settlement — so money movement is solved, not something you bolt on later.

The honest boundary

Be clear-eyed about the split, because it's what keeps your margins yours. VBWD is the productization layer around the model, not the model.

You bring: the LLM provider keys (OpenAI, Anthropic, or whoever — VBWD's LLM connection is provider-agnostic, and choosing/optimizing the provider is your call); the prompts and guardrails that make the assistant good and safe for its job; and any domain knowledge or RAG data — the documents, embeddings, and retrieval logic that make it an expert rather than a generic chatbot.

VBWD brings: the chat surface, the credit-and-subscription billing, multi-tenant accounts with RBAC isolation, the Telegram delivery, the CMS, and the MCP-native API. It does not write your prompts, it does not host or train the model, and it does not supply your domain data. If your assistant is bad, that's your prompts and your retrieval — not the platform. That boundary is a feature: it means the intelligence, the data, and the customer relationship stay entirely yours.

A rough build outline

The core workflow, in a few concrete steps:

• 1. Stand up the SDK. Clone the public SDK, bring up the backend, and enable the plugins you need — chat + LLM, token_payment, subscription, bot_telegram, cms, mcp. Because plugins toggle at runtime, you turn capabilities on as you go rather than forking the core.
• 2. Wire your provider. Configure the LLM connection with your provider keys and model. Drop in your system prompt, guardrails, and — if you have domain data — your RAG source so retrieval feeds context into each answer.
• 3. Meter the assistant. Connect each chat interaction to token_payment so a message or query consumes credits. Decide your unit economics: what a "message" costs in credits, and how that maps to what you pay your provider per token.
• 4. Package the plans. Use subscription to define tiers — e.g. a monthly plan that includes a credit allowance, plus add-ons and top-ups for heavy users. Checkout and invoicing come with it.
• 5. Isolate tenants. Each customer signs up into their own workspace via RBAC + multi-tenant, keeping their conversations, users, and data separate.
• 6. Extend the surface. Point bot_telegram at the same assistant for a chat-app channel, build your marketing and docs in the CMS, and expose the assistant over MCP so it's callable by other agents.

Verticals already built on VBWD — a tarot app, a dice-market game (bdv), a pharmacy shop (shop_pharma) — are proof the same core stretches to very different products. An assistant SaaS is just another vertical composed from these plugins.

Monetization, and why owning it beats renting

You have two revenue levers and they combine well. Credits (token_payment) give you usage-based revenue that scales with consumption and protects your margin — you set the credit-to-provider-cost ratio, so heavy users pay more and you never sell messages below cost. Subscriptions give you predictable recurring revenue: monthly tiers with included allowances, then metered overage on top. Most successful assistant products run both — a base plan for predictability, credits for elasticity.

Here's why owning the stack matters. If you build on a closed chatbot platform, you rent your billing, you rent your accounts, and — worst of all — your customer data and your margins live on someone else's terms. They can change pricing, take a cut, or lock your data in. VBWD is self-hosted and source-available: your customer data sits in your database, your provider keys stay yours, and the margin between what you charge and what the model costs is entirely yours to keep. Own it, don't rent it. And because the LLM connection is provider-agnostic, you're never trapped — when a cheaper or better model appears, you switch providers without rebuilding your product.

Get started

Clone the public SDK and start composing: github.com/VBWD-platform/vbwd-sdk-public. If you'd rather have an enterprise installation stood up for you, get in touch.

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.

Build a business with VBWD — the series:Mobile game · Travel aggregator · Marketplace · Booking SaaS · AI assistant SaaS (this one)