A hotel booking site, a clinic portal, a software store, a data marketplace, a GitHub-gated shop — VBWD ships all five as working demo instances you fork and rebrand. Starting from zero is optional.
Rewritten for redrobot.
Open a fresh VBWD install and something strange greets you: it is not empty. There are pages, plans, an admin panel, a checkout that works. That is the point people miss when they hear “self-hosted platform” and picture a blank editor. VBWD hands you five running businesses to take apart, and the fastest way to understand the thing is to ask what each of those five is actually made of.
A demo is a constellation, not a template
Start with vocabulary, because the wrong word here sends you down the wrong path. A VBWD demo instance is not a theme you copy and a not a screenshot you imitate. It is a ready-made vertical: real CMS content bolted onto a specific constellation of plugins, wired together and populated so the whole thing runs the moment you import it.
The reason it works this way is a design decision that runs through the entire platform. The core knows nothing. It has no concept of a hotel room, a patient appointment, or a software licence. It handles the machinery every subscription business shares, accounts, billing, plans, admin, CMS, and every scrap of domain behaviour lives in plugins that clip onto seams the core exposes. A demo is simply a chosen set of those plugins plus the content that shows them off. The architecture pages lay out why the boundary sits exactly there. The practical payoff: your changes and the platform’s upgrades stop colliding, because they live on opposite sides of that line.
Which reframes what you are buying into. You are not adopting five products. You are adopting one agnostic core and five worked examples of how plugins compose on top of it. Change the plugins, change the content, and the vertical becomes yours.
Getting the base breathing
One command stands the platform up:
./recipes/dev-install-ce.sh
It runs on Python/Flask, PostgreSQL, Vue 3, and Docker, and when it finishes you have a live instance you own end to end. If you already know which vertical you want, skip the import-afterwards dance and name the plugin set at install time with the installer’s --plugins-list flag. Same destination either way: a running site that answers to you.
Five starting points, each solving a different problem
Here is the useful way to read the five: not as a menu of finished apps, but as five answers to “what does this kind of business need that the core does not give me for free.”
core is the honest baseline, the one the other four are built on top of. Accounts, authentication, subscription plans, invoicing, admin backoffice, CMS, and nothing domain-specific. That absence is the feature. If your product is not a hotel, a clinic, or a store, you start here and decide what the domain is yourself, pulling in whatever you need from the plugin catalogue. Most founders building something novel should fork this and nothing else.
softwarestore answers “how do I sell digital goods.” Product listings, product types, a catalogue you can filter, checkout, and the subscription and invoicing engine underneath. It shows the shop and catalogue plugins composing into a browsable storefront rather than a flat price list. Selling tools, licences, or downloads of any kind, not only software, this is your closest fit.
hotel answers “how does an enquiry become a paid reservation.” Room or unit listings, availability, and a booking flow, scoped deliberately for boutique hotels and bed-and-breakfasts rather than chains. The content and config assume a handful of units and a direct relationship with the guest, which is exactly what small independent properties actually run.
doctor answers “how does a private practice take on paying clients.” A patient-facing site, a service and plan structure, and the account and billing layer a clinic or independent therapist needs. It is built around the private-practice model, where the practitioner owns both the relationship and the payment. It handles the business mechanics; the medical and privacy side stays yours, and we will get to why that matters.
ghrm answers a narrower question that overlaps with none of the above: “how do I deliver software gated behind GitHub.” Access to packages and bundles is tied to a customer’s GitHub identity, so buying or subscribing grants an entitlement through their GitHub account instead of a licence key they can lose. If your model is “pay, then get into a private repo or release,” this vertical already does the gated delivery that softwarestore’s storefront does not.
From worked example to your product
The route from demo to live business is the same for all five, and none of it means touching platform code.
Import the vertical into a fresh install, and its content and plugins are running locally. Then the real work: replace the example pages, plans, and settings with your own services, prices, policies, and copy. This is where most of your hours should go, because this is the part that actually makes it a business rather than a rehearsal. Rebrand by swapping logos and setting colours through theme tokens rather than editing component styles, so your look survives the next platform update, then point a custom domain at it. Trim the plugin set, the demo’s selection is a suggestion, not a contract, so switch off what you do not need and add what you do straight from the admin panel, no redeploy required. Then ship it on your own infrastructure.
The documentation walks the install, import, and deploy steps in order, and the features overview is the map you want open while deciding which plugins earn a place in your set.
What the demo does not do for you
A starting point is a starting point, and pretending otherwise is how projects embarrass themselves. Three things stay firmly on your side of the line.
The content is placeholder. Shipping a demo unchanged is shipping someone else’s example text under your logo. The demo spares you the plumbing, never the thinking.
Self-hosted means you run the infrastructure. Uptime, backups, updates, all yours. That is the trade for owning your data and skipping per-seat platform fees, and for plenty of businesses it is the right trade, but it is a genuine operational job, not a checkbox.
And for doctor and hotel especially: the demo makes you compliant with exactly nothing. A clinic portal running on VBWD is still your clinic portal, and every medical-privacy, data-protection, and consumer obligation that applies to your business applies unchanged. The software does not make you HIPAA-certified or GDPR-compliant. It gives you something to operate inside your own legal and compliance obligations. Treat the vertical as a head start on the product and treat compliance as work you still own.
The licence, plainly
VBWD is source-available under BSL 1.1 with a Bitcoin-denominated use grant. It is free for commercial use while your annual VBWD-attributable sales stay below the value of 6.7 BTC, measured as the arithmetic average of daily BTC/USD across the reporting year. Cross that, and you need a commercial licence. The threshold sits high enough that a founder validating an idea, an agency building for a client, or an OEM shipping a first product can build and sell without paying for a licence until the business is genuinely working. Source-available, to be clear, is not public domain: you get the source and broad commercial rights under the grant, not an unrestricted free-for-all.
The trade you are actually making
The five demos exist so that “build your vertical” stops meaning “rebuild the same subscription platform a fourth time.” Pick the one nearest your business, core for something general, softwarestore for digital goods, hotel for small hospitality, doctor for private practice, ghrm for GitHub-gated delivery, import it, swap in your own content, rebrand through theme tokens, tune the plugin set, and deploy on your own hardware. The platform carries what every vertical shares. You bring the product, the policies, and the operations. That division is the whole pitch, and it is an honest one.
Learn more about VBWD
VBWD is a self-hosted, source-available platform for building subscription products, marketplaces, and AI-powered apps. Explore it further:
- 🌐 Website and documentation: vbwd.cc — see the plugins, architecture, and developer docs.
- 💻 Source code and plugins on GitHub: github.com/VBWD-platform
- 🎥 Watch VBWD in action: demo video 1 and demo video 2
- 💼 Follow the project on LinkedIn: linkedin.com/company/vbwd
VBWD is source-available — get the SDK on GitHub.