Most SaaS projects die in the first month, not because the idea is wrong, but because the founder spends that month rebuilding things every product already needs: auth, billing, a plan catalogue, an admin backoffice, a CMS, a checkout. By the time any of that works, the energy for the actual product is gone. You do not have to start from zero. VBWD ships five demo instances, each a working vertical you can fork, rebrand, and put in front of customers.
A demo instance is not a marketing screenshot and it is not a template you copy-paste. It is a ready-made vertical: real CMS content plus a specific constellation of plugins that you import into a fresh VBWD install and then make your own. VBWD itself is self-hosted and source-available, built on Python/Flask, PostgreSQL, Vue 3, and Docker. The core is deliberately agnostic. It knows nothing about hotels, clinics, or software stores. All of the domain behaviour lives in plugins, and a demo instance is a curated set of those plugins wired to worked example content.
Because the platform is plugin-based, a demo is just a starting configuration. You install the base, import the vertical, and you have a running site with pages, a plan structure, an admin panel, and the domain features that vertical needs. Then you change the content, the config, and the branding until it is your product. The architecture pages explain the agnostic-core split in more depth if you want to understand why the boundary is drawn where it is; the short version is that it keeps your customisations from fighting the platform's upgrades.
Getting the base running is one command:
./recipes/dev-install-ce.shIf you already know which vertical you want, you can pick the plugin set up front with the installer's --plugins-list flag rather than importing afterwards. Either way you end up in the same place: a running instance you own end to end.
Each demo ships with worked content and its own plugin set. Here is what each one is for.
The core demo is the foundation the other four build on: user accounts, authentication, subscription plans, invoicing, the admin backoffice, and the CMS. If your product does not fit one of the specialised verticals, start here. It gives you a functioning subscription business with nothing domain-specific bolted on, which means you decide what the domain is. Most founders who are not building a hotel, clinic, or software store should fork this one and add the plugins they need from the plugin catalogue.
The softwarestore demo is a storefront for selling software: product listings, product types, a catalogue with filtering, checkout, and the subscription and invoicing machinery behind it. If you sell tools, licences, or downloadable products, this is the closest fit. It shows how the shop and catalogue plugins compose into a browsable store rather than a flat price list, and it is a reasonable base for any digital-goods business, not only software.
The hotel demo is a booking vertical aimed at boutique hotels and bed-and-breakfasts: room or unit listings, availability, and the booking flow that turns an enquiry into a paid reservation. It is deliberately scoped for small independent properties rather than large chains, so the content and config assume a handful of units and a direct-booking relationship with the guest. If you run or build for small hospitality operators, this is your starting point.
The doctor demo is a portal for private clinics and independent therapists: a patient-facing site, service and plan structure, and the account and billing layer that a practice needs to take on private clients. It is built for the private-practice model, where the practitioner owns the relationship and the payment. As with the hotel vertical, it handles the mechanics of running the business; the medical and privacy policies are yours to define, which we will come back to.
The ghrm demo distributes software gated behind GitHub. Access to packages and bundles is tied to GitHub identity, so customers who buy or subscribe get their entitlement through their GitHub account rather than a separate licence key to lose. If your distribution model is "pay, then get access to a private repo or release," this is the vertical that already does it. It overlaps with softwarestore but solves a different problem: not the storefront, the gated delivery.
The path from demo to product is the same for all five, and none of the steps require touching platform code.
Import it. Start from a fresh install and import the vertical you chose. You now have its content and plugins running locally.
Customise the content and config. The demo's pages, plans, and settings are examples. Replace them with your real content: your services, your prices, your policies, your copy. This is the part that actually makes it your business, and it is where most of your time should go.
Rebrand. Swap logos and set your colours through theme tokens rather than editing component styles, so your branding survives platform updates. Point a custom domain at the instance. At this stage it stops looking like a demo.
Enable and disable plugins. The demo's plugin set is a suggestion, not a contract. Turn off what you do not need and add what you do from the catalogue. The plugin toggles are part of the admin panel, so this is configuration, not deployment.
Deploy. Ship it. Because the whole thing is Docker-based and self-hosted, you deploy it on your own infrastructure and keep control of your data and your customers. The documentation walks through the install, import, and deploy steps in order, and the features overview is a useful map of what each plugin adds before you commit to a plugin set.
A demo instance is a starting point, not a finished product, and it is worth being blunt about what that means.
First, the content in a demo is example content. Real customers need real policies, real service descriptions, real pricing, and real data. Shipping a demo unchanged is shipping someone else's placeholder text with your logo on it. The demo saves you the plumbing, not the thinking.
Second, self-hosted means you operate the infrastructure. Uptime, backups, and updates are yours. This is the trade for owning your data and avoiding per-seat platform fees, and for many businesses it is the right trade, but it is a real operational responsibility, not a checkbox.
Third, and most important for two of the verticals: the doctor and hotel demos do not make you compliant with anything. A clinic portal that runs on VBWD is still your clinic portal, and the medical-privacy, data-protection, and consumer obligations that apply to your business apply exactly as they would on any other stack. A demo does not make you HIPAA-certified or GDPR-compliant; it gives you software you then have to operate within your own legal and compliance obligations. Treat the vertical as a head start on the product, and treat compliance as work you still own.
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 over the reporting year. Above that, you need a commercial licence. That threshold is high enough that a founder validating a vertical, an agency building for a client, or an OEM shipping a first product can build and sell on VBWD without paying for a licence until the business is genuinely working. It is source-available, not public domain; you get the source and broad commercial rights under the grant, not an unrestricted licence.
The five demo instances exist so that "build your vertical" does not mean "rebuild the same subscription platform for the fourth time." Pick the one closest to your business — core for a general subscription product, softwarestore for digital goods, hotel for small hospitality, doctor for private practice, ghrm for GitHub-gated distribution — import it, replace the example content with your own, rebrand through theme tokens, adjust the plugin set, and deploy on your own infrastructure. What you save is the plumbing. What you still have to bring is the product, the policies, and the operations. That is the right division of labour: the platform handles what every vertical needs, and you spend your time on what makes yours worth paying for.
Ready to start? Run ./recipes/dev-install-ce.sh, then browse the plugin catalogue to see which constellation matches the vertical you have in mind.