Most booking software for a small hotel or B&B asks you to make an expensive choice early: rent a hosted platform that takes a cut of every reservation and holds your guest data, or hire a developer to build something bespoke that you then have to maintain. Neither is a good fit for a six-room guesthouse or a two-person agency building sites for hospitality clients.
There is a third path. VBWD is a self-hosted, source-available platform, and it ships ready-made demo instances you can start from. One of them is a boutique-hotel/B&B setup. Instead of assembling a booking system component by component, you import a working example, then rebrand and reconfigure it until it is yours. This article walks through what that actually involves, and where the honest limits are.
A demo instance is not a template in the marketing sense. It is a concrete, runnable configuration: a set of CMS content (pages, images, copy) plus a specific set of plugins wired together and pre-populated with sensible defaults. The hotel instance, for example, comes with room listings, a booking flow, rate structures, and landing pages already in place so you can see the whole thing work before you change a line of it.
The platform underneath is deliberately plain. VBWD runs on Python and Flask with a PostgreSQL database, a Vue 3 frontend, and Docker for packaging. The core is agnostic — it knows nothing about hotels, appointments, or invoices on its own. Every domain behaviour lives in a plugin. That separation is why the same core can back a hotel instance and a doctor/clinic instance with no forking: you swap the plugin set and the content, not the engine. You can see the available building blocks on the plugins page.
Because you host it yourself, a couple of business facts follow directly. There is no platform commission on bookings — the money moves between your guest and your payment provider, not through a middleman. Your guest data sits in your database, on infrastructure you choose, which makes EU-friendly data residency a configuration decision rather than a feature you have to beg a vendor for. The licence is BSL 1.1, which is free for commercial use as long as your annual VBWD-attributable sales stay under the value of 6.7 BTC per year; above that you need a commercial licence. It is source-available, not public-domain — you get the code and the freedom to run and modify it, within those terms.
Getting the demo running is an import step, not a build-from-scratch step. You bring up the stack with Docker, then import the hotel instance's CMS content and enable its plugin set. What lands is a functioning site: room pages, a booking widget, rate tables, and the supporting landing pages, all populated with placeholder content.
The value of starting here is that you are debugging a working system rather than an empty one. When you change a rate or a room description, you can see immediately whether it flows through to the booking page and the invoice. You are never staring at a blank admin screen wondering which of forty settings matters. The documentation covers the import mechanics and the order plugins need to be enabled, which matters because some plugins depend on others being present first.
For an agency, this is the part that changes the economics. A demo instance is a repeatable starting point. The first hotel client takes the longest because you are learning the platform; the second and third are mostly content and branding work on top of a structure you already understand.
The booking plugin is the heart of the hotel instance. It handles the things a property actually sells: rooms (or, in other instances, services and time slots), the rates attached to them, and availability. In practice your configuration work here is:
Because the core is agnostic, the booking plugin does not try to also be your accounting system. It composes with separate billing and invoice plugins. When a guest books, the booking plugin produces the reservation and hands the money side to billing, which generates the invoice. That separation means you can change how you bill without touching how you take reservations, and vice versa. The features overview lays out how these pieces fit together across an instance.
Payment is a swappable plugin, not a hardwired dependency. This is a deliberate design choice and a practical one for small operators: the payment provider that is cheapest or best supported in your country is rarely the one a hosted platform would have picked for you. You choose a payment plugin, configure it with your own merchant credentials, and the booking-to-invoice flow captures through it. If you later switch providers, you swap the plugin rather than migrating your whole system. The billing documentation explains how the billing and payment plugins interact and what a captured payment triggers downstream.
Branding is where the demo stops looking like a demo. The CMS gives you the landing pages, the room pages, and the marketing content, all editable. You replace the placeholder copy and images, apply your colours and logo, and the site becomes the property's own. For a hotel this is not cosmetic — the landing page and room descriptions are your primary sales surface, and they need to read like your property, not like sample text.
Search visibility is a real problem for any Vue-based site, because a single-page application renders in the browser and a naive crawler sees an empty shell. VBWD addresses this with an SEO renderer that produces crawlable versions of the pages, so your rooms and landing content are visible to search engines rather than hidden behind JavaScript. For a small property that depends on being found for "B&B in [town]" searches, this is the difference between having a website and having a website anyone can find.
A demo instance is a starting point, and it is worth being clear about what that means so you plan the work correctly.
First, it is a starting point you customise. The demo's rates, cancellation policies, room content, and copy are examples. None of them are your business rules, and you should expect to replace all of them. The demo saves you the structural work, not the thinking about how your property actually operates.
Second, you operate the infrastructure. Self-hosting is the reason you keep your data and avoid a platform cut, but it also means the server, backups, updates, and uptime are yours to manage. If you are an agency, this is billable operations work you can offer clients. If you are a single property owner without technical help, budget for someone to handle the hosting, or plan to learn the Docker basics involved.
Third, and most important for hotels: channel-manager and OTA synchronisation is not built in. If you sell rooms through Booking.com, Expedia, or Airbnb as well as your own site, keeping availability in sync across those channels is integration work, not a checkbox. The booking plugin manages your inventory and your direct bookings well. Connecting it to external distribution channels is a project you scope separately, either against a channel manager's API or through a third-party sync service. Going in expecting this to exist will lead to a bad surprise; going in knowing it is custom work lets you plan for it or decide direct-only bookings are enough.
For a small property or an agency serving them, the hotel demo instance is a way to skip the blank-page phase of building a booking site without signing up for a hosted platform's commission and data terms. You import a working system, reconfigure rooms, rates, and availability, wire in the payment provider that suits you, rebrand the CMS pages, and rely on the SEO renderer to keep them findable. You own the data, you pay no platform cut, and the licence stays free until you are doing real volume.
The trade is that you own the operations and that anything touching external booking channels is integration work. For a property focused on direct bookings — which is exactly the property that resents paying OTA commissions — that trade is usually the right one. For an agency, a repeatable demo instance turns each hospitality client into a content-and-branding job on top of a structure you already know, which is a far better margin than building each site fresh.
Start from the hotel demo, keep what fits, and replace the rest — the docs are the place to begin.