Booking, patient accounts, secure messaging, an AI assistant, membership plans and a loyalty programme — a whole clinic patient-management stack you self-host and own, instead of renting.
Clinic managers juggle scheduling, patient retention, and software that owns their data; VBWD puts the whole patient-management stack on infrastructure the clinic controls.
The software running your clinic is renting you your own patients
Most clinic management platforms are hosted SaaS. You pay per seat, per month, per patient, or some blend of all three. The vendor holds the database. The vendor decides when your appointment book gets a new feature, when prices go up, and what happens to your patient records if you ever want to leave.
For a practice operator, that is a quiet but real business risk. Your patient list is the most valuable asset the clinic owns, and it sits on infrastructure you do not control, governed by a contract you did not write.
VBWD is a different arrangement. It is a self-hosted, source-available platform you install on your own server. You run the patient-management stack; nobody rents it back to you. This article walks through what that stack gives a clinic and, just as importantly, where its limits are.
The operational problem with hosted SaaS
Three costs tend to creep up on clinic managers using hosted patient software.
- Per-seat pricing that punishes growth. Add a front-desk hire or a locum practitioner and the monthly bill climbs, whether or not you used more of the product.
- Feature lock-in. Booking, messaging, memberships, and loyalty are usually four separate subscriptions from four vendors, none of which talk to each other cleanly.
- Exit cost. Migrating years of patient history off a hosted platform is deliberately painful. That pain is the vendor’s retention strategy.
The alternative is not building software yourself. It is running a platform where the pricing is your hosting bill, the features live under one roof, and the data is already on your side of the fence.
What VBWD gives a clinic as a patient-management stack
VBWD has an agnostic core with functionality delivered as plugins. For a clinic, you assemble the stack from the pieces that matter to a practice. Here is how they map to day-to-day operations.
Booking and appointments. The scheduling plugin handles multi-practitioner calendars: each clinician has their own availability, and patients book against real open slots rather than a request form someone re-keys later. For a manager, that means fewer double-bookings and less front-desk time spent on the phone. Availability rules live in your system, not a third party’s.
Patient accounts and a portal. Every patient gets a secure account. From that portal they see their upcoming appointments, manage their details, and interact with the clinic without emailing personal information around in plain text. This is the anchor the rest of the stack hangs off — one identity per patient, under your control.
A secure messenger. Patient-to-clinic communication runs through a built-in messenger instead of scattered across personal email, SMS, and WhatsApp. Threads stay attached to the patient account, so a message about a repeat prescription or a follow-up is in one auditable place your staff can actually find.
An LLM RAG chatbot grounded in your own content. The chatbot answers patient questions using a retrieval layer built from the clinic’s own material — opening hours, preparation instructions, cancellation policy, which practitioner treats what. Because it is grounded in your content, it does not free-associate answers about your clinic. In practice it deflects a slice of routine front-desk load: “how do I prepare for my appointment”, “can I move my booking”, “do you take my insurance”. Technically, the bot rides a search seam that deliberately blocks privacy-sensitive slices of data, and it talks to language models through a connection manager you configure — so you decide which model provider, if any, sees which content.
Subscription and membership plans. The subscription plugin supports recurring care plans and memberships: a monthly wellness plan, a bundled course of treatments, a family membership. Billing recurs automatically. For a manager this turns unpredictable episodic visits into a base of predictable recurring revenue, which is the single biggest lever on a clinic’s cash flow.
A token/credit system as a loyalty programme. VBWD includes a token/credit mechanism you can run as loyalty: patients earn points or credits for visits and for referrals, and redeem them for perks. Retention and word-of-mouth are cheaper than acquisition, and this gives you a structured way to reward both without a separate loyalty vendor. You can see the full function set on the features overview.
The point is not any single feature. It is that booking, accounts, messaging, the bot, memberships, and loyalty share one patient identity and one database, instead of being six integrations you maintain.
The data-ownership and GDPR angle
This is where self-hosting earns its keep for a clinic. Patient data is special-category data, and where it lives matters.
Because you deploy VBWD yourself, you choose the hosting. Put it on an EU-resident server and your patient data has genuine data residency — not a promise in a sub-processor appendix, but a fact of your architecture. You are the data controller. Your processor list is short and explicit because you know exactly which services touch the data, rather than inheriting a hosted vendor’s sprawling chain of sub-processors.
Granular access control backs this up. Admin, staff, and patient access are separated, with per-role permissions: front-desk, practitioner, and manager do not all see the same things. A receptionist managing the calendar does not need the same view as a clinician reading clinical notes, and the permission model lets you enforce that. The architecture documentation covers how the roles and the plugin platform fit together.
The stack itself is conventional and inspectable: Python and Flask, PostgreSQL, Redis, a Vue 3 and TypeScript frontend, all in Docker. One backend serves both the web app and native mobile clients. Nothing here is exotic; any competent hosting partner can run it, and because it is source-available you or your IT contractor can read exactly what it does.
Be honest about what this does not do
Self-hosting on an EU server gives you data residency and controller status by architecture. It does not, by itself, make your clinic compliant with anything.
- VBWD is not HIPAA-certified and is not a certified medical device. Do not read the data-ownership story as a compliance certificate.
- Lawful basis for processing, a DPIA where required, retention schedules, breach procedures, and staff training remain your responsibility as the operator.
- Any medical-records regulations specific to your jurisdiction and speciality are yours to meet. VBWD gives you the control surface to meet them; it does not meet them for you.
- Self-hosting means you own uptime, backups, and updates. That is the trade for control — either your team handles it or you pay a hosting partner who does.
A clinic manager should treat VBWD as strong infrastructure for a compliant operation, not as compliance in a box.
What it costs and how you run it
The platform runs on a small VPS. There is no per-seat licence: add front-desk staff or practitioners without the bill tracking your headcount. Under the Business Source License 1.1 it is free for commercial use until your VBWD-attributable annual sales exceed the value of 6.7 BTC, and the licence converts to Apache-2.0 on its change date — so the ceiling only matters to a genuinely large operation, and the long-term direction is fully open. The billing plugin handles invoicing and the recurring memberships described above, so the money side lives in the same system as the patients.
The takeaway
For a clinic manager, VBWD is a way to run booking, patient portals, secure messaging, a grounded FAQ bot, memberships, and loyalty as one owned system rather than a stack of rented ones. The upside is real cost control, no per-seat penalty on growth, patient data that sits where you put it under your control, and no vendor holding your records hostage. The cost is that you take on hosting and compliance responsibility that a SaaS vendor would otherwise carry — imperfectly, and on their terms.
If your clinic’s software strategy currently amounts to hoping four vendors keep their prices flat, owning the stack is worth costing out.
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
