A dentist, a physiotherapy clinic, a driving instructor, a small law office. They all want the same thing: let people book time online, take a deposit or full payment, and stop losing an hour a day to phone tag. Most of them get quoted a recurring per-seat SaaS bill that grows with their client list, and none of them own the data at the end of it.
If you run an agency or do integration work, this is a good business to be in. The build is repeatable, the ongoing relationship is real, and you can price it as a managed service instead of a one-off project. This article walks through delivering a booking-and-payments site for a local client on VBWD, a self-hosted, source-available platform, and how to turn that build into recurring revenue you keep in full.
The concrete deliverable is a branded website on the client's own domain where their customers can see services, pick an available slot, pay, and receive an invoice. Behind it, the client's staff get an admin area scoped to their role: the front desk sees the day's schedule, each practitioner sees only their own bookings, and the owner sees the money.
Technically it is one VBWD instance: Python/Flask and PostgreSQL on the backend, a Vue 3 frontend, all running under Docker. The platform has an agnostic core and a plugin layer, which matters here because booking, invoicing, and payment are separate plugins that compose rather than one monolith you have to fork. You are assembling capabilities, not writing a booking engine from scratch. Browse the plugin catalogue to see what is already available before you decide what, if anything, you need to build.
VBWD ships with a one-command installer that provisions the backend API, PostgreSQL, and Redis via Docker Compose. On a small VPS — the kind that costs a few euros a month — this is enough to run a single local client comfortably. You do not need Kubernetes or a managed database for a clinic that takes forty bookings a week.
# On a fresh VPS
git clone <your-instance-repo>
cd vbwd
./recipes/dev-install-ce.shThe installer brings up the services, runs database migrations, and seeds the default roles and permissions. At this point you have a working platform with an admin login. The documentation covers the environment variables you will set per client — database credentials, the JWT secret, the mail server for confirmations — and the compose layout you use to keep each client's instance isolated on its own domain.
Booking is a plugin that models the things a scheduling site needs: services, practitioners, availability windows, and appointments. You enable it, then spend most of your configuration time here, because this is where a booking site is either useful or useless.
Configure the real rules of the business, not placeholders:
This is the part clients underestimate and the part you should not. A booking system that offers slots the practitioner cannot actually work is worse than a phone number. Sit down with the client and write the rules explicitly before you configure them. The plugin gives you the fields; the correct values come from the business.
Once a customer picks a slot, the booking composes with the platform's billing and invoice engine. Booking produces the line items — service, duration, price — and the invoice engine turns them into a real invoice with tax handling. You do not reconcile two systems; the booking hands off to billing inside the same instance.
Payment collection is itself a swappable plugin. VBWD supports Stripe, PayPal, and YooKassa, so you match the provider to the client's country and existing merchant account rather than forcing one gateway on everyone. The client connects their own account; the money lands in their bank, not yours. See how invoicing and payment capture fit together on the billing overview and features pages.
One rule with no exceptions: test the full payment flow in the provider's sandbox before you go live. Book a slot, pay with a test card, confirm the invoice is generated, confirm the confirmation email arrives, then trigger a refund. Do this for every provider you enable. Payment bugs discovered in production cost you the client's trust and possibly their money.
The client wants their logo, their colours, their copy — not a generic booking widget on a subdomain. VBWD's CMS builds the public-facing pages through layouts and widgets, which means you assemble the homepage, the services page, and the about page without editing the frontend router or touching Vue source.
You place a booking widget into a CMS layout, drop in the branded content around it, and the page is live on the client's domain. This is deliberate: it keeps the branded surface in data the client can partly own, and it keeps you from forking the frontend for every client's colour scheme. When the client wants a new page or a copy change six months later, it is a CMS edit, not a redeploy.
A booking site has at least three kinds of user, and they must not see each other's world. VBWD separates access through granular role-based access control — in fact three cooperating role systems: one for the top-level account type, one that gates the admin area, and one that gates what a logged-in customer can reach.
For a typical clinic you map it like this:
Configure these once, per client, as part of the build. Getting RBAC right is what separates a professional handover from a system where the receptionist can accidentally read the owner's revenue.
This is where the model gets interesting for an integrator. Because the platform is self-hosted and source-available, you are not reselling someone else's SaaS seat — you operate the instance. That means the ongoing relationship is a managed-service contract, not a referral fee.
A workable structure:
You keep 100% of both. There is no platform cut on the bookings or the payments flowing through the client's site, because you are not routing them through a marketplace — the client's Stripe or PayPal account collects directly. The client owns their data and their instance; if they ever leave, they can take it with them, which is a selling point rather than a risk.
The licence supports this cleanly. VBWD is BSL 1.1: free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year, which covers essentially every local-client integration you will run. It is source-available, not public domain — you get the source and the right to operate it commercially under those terms, not a no-strings CC0 dump. The pricing page has the exact terms; read them once so you can answer the client's lawyer without guessing.
Sell this accurately or it will bite you later.
First, self-hosted means you are the operator. Uptime, backups, and updates are your job now. If the VPS goes down on a Saturday, the client calls you, not a vendor's support line. Price the recurring fee to cover that responsibility and actually do the backups — test a restore before you need one.
Second, a booking site is only as good as the scheduling rules you configure. The plugin does not know the client's business. If availability, buffers, and notice periods are wrong, customers will book slots that cannot be honoured. Budget real time with the client to get these right, and revisit them after the first busy month.
Third, payment flows must be proven in sandbox before launch, and re-tested whenever the client changes plans or providers. This is not optional diligence; it is the difference between a smooth launch and an emergency.
A booking-and-payments site for a local client is a repeatable build on VBWD: stand up an instance with the one-command installer, configure the booking plugin against the client's real scheduling rules, compose it with the billing engine and the payment plugin that suits their market, brand the public pages through the CMS, and lock down access with role-based control. The result is a site the client owns, on their own domain, taking payments into their own account. You capture the value as a build fee plus a recurring managed-service fee, and you keep all of it. The work is honest — you operate the thing — but the economics beat reselling per-seat SaaS, and the client ends up with something they control.
Ready to scope your first build? Start with the documentation and the plugin catalogue to map the client's requirements to what ships in the box.