Every platform promises extensibility. The word appears in every pitch deck, every README, every landing page. But a promise of extensibility is architecture on paper. The real test is different, and it is brutally simple: can you point at products that already run on it — products that don't resemble each other? A platform proves it is genuinely general when the things built on top diverge, when they are different shapes of business, not five copies of the same demo with a new logo.
VBWD can point at that. Several real vertical products already run on the same core, and they are deliberately unalike. Not variations on a theme — genuinely different product categories, sharing one backend.
Consider what these have to hold in common, and how little that turns out to be.
A tarot app is a content product with a credit economy. People read, browse, and consume — and they buy tokens or credits to unlock what they want. The interesting part is the content and the metered spend of those credits. That is one product shape: content plus a token/credit purchase model.
A dice-market game (bdv) is nothing like that. It is a game with an economy that lives on the backend — balances, transactions, the rules that make the market work. The differentiated part is the game logic and its internal economy. Different shape entirely.
A pharmacy shop (shop_pharma) is regulated retail commerce. Products, orders, stock, shipping — with the added weight that pharmacy carries. The hard, distinctive work is the retail flow and the regulatory constraints around it. A third shape, again unlike the first two.
And dataset publishing is digital-goods sales: you sell data and access to it, no physical inventory, no shipping, entitlement instead. A fourth shape — selling bytes, not tarot readings, not game turns, not medicine.
Content-with-credits. A game economy. Regulated physical retail. Digital-goods sales. If a single core can carry all four honestly, the extensibility claim stops being marketing and starts being evidence.
Look at what those four products need that they don't want to build. Every one of them needs to know who the user is. Every one needs to take money. Several need subscriptions or recurring billing. All of them need a catalogue of some kind — readings, game items, medicines, datasets. Some need booking; some need to work on mobile. And all of them, being real businesses handling real users and real payments, need identity, permissions, and the plumbing of settlement.
That list — identity, billing, subscriptions, payments, catalogue, booking, and mobile — is shared substrate. It is the same underneath a tarot app and a pharmacy. There is no version of "who is this user and did they pay" that is meaningfully different because you sell dice turns instead of dermatology creams. It is the undifferentiated 80% of every product: essential, expensive to build well, and completely invisible to your customer as a differentiator. Nobody chose the pharmacy because its authentication was tasteful.
VBWD's design takes that seriously. The core is intentionally agnostic — it knows nothing about tarot or pharmacies or games. Capabilities live in plugins that toggle on and off without a restart, in their own space, without forking the core. So the tarot app enables what it needs — content, a token/credit economy, checkout — and the pharmacy enables shop, orders, stock, shipping. The core underneath is the same core. Identity is the same identity. The payment layer is the same payment layer — one that already speaks to many providers (Stripe, PayPal, and regional processors) and supports non-custodial crypto settlement to the merchant's own wallet.
Which means each of these products is, in the end, mostly the differentiated slice on top. The tarot team built the tarot. The game team built the game economy's rules. The pharmacy team handled the regulated retail flow. The dataset team built the publishing and entitlement model. That slice — the thing that makes the product that product — is where the work went, and it is the work that should have gotten the attention. The rest was already there.
Here is where showcase pieces usually lie, so let's not. None of these products built themselves. Each one required real product work — real design decisions, real domain knowledge, real iteration. A pharmacy still has to get regulated retail right. A game still has to be a good game with an economy that isn't broken. A dataset business still has to have data worth buying. VBWD did not make any of that easy, because none of that is the platform's job.
What the platform did was remove the undifferentiated 80% — the identity, billing, subscriptions, payments, catalogue substrate that every one of these products needed and none of them wanted to reinvent. That is a real and large saving. It is not magic. You still build your product; you still own the operations of self-hosting the core you run. The claim is narrow and true: the platform takes the part that is the same everywhere off your plate, so your team spends its scarce attention on the part that is only yours.
That is what the four products demonstrate, and it is why they are better evidence than any feature list. They are not the same product with different branding. They are different businesses that happened to need the same foundation — and got it — and then each went and built the thing on top that no platform could have built for them.
The best proof of extensibility is the kind you can inspect. The public SDK is open for exactly that: github.com/VBWD-platform/vbwd-sdk-public. Read the core, look at how plugins attach, and decide whether the substrate fits the product you have in mind. If you want to talk through whether your product is one more shape this core can carry, get in touch.
Proof beats promises. Varied, real products already run here — and each one is mostly the part that only its team could have built.
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.