The hard part of selling medicine online isn’t the checkout

If you run a US pharmacy or health-product store, the shopping cart is the easy 10%. The other 90% is proving that the right product went to the right person in a state where you are licensed to sell it, and keeping a record you can defend if a board of pharmacy asks. Generic e-commerce software is built to sell as many units as possible to as many people as possible. That default is exactly wrong for regulated health products.

VBWD is a self-hosted, source-available shop platform (Python/Flask, PostgreSQL, Vue 3, Docker) built as an agnostic core with plugins for shop, product types, discounts, invoicing, and payments. It gives you technical controls that support a compliance program. It does not make you compliant, it is not a certification, and nothing here is legal advice.

The US is a patchwork, and most shop software ignores that

There is no single federal “sell drugs online” licence. Pharmacy practice is licensed state by state through each state’s board of pharmacy, and shipping a prescription into a state generally means holding a licence recognized there. Layered on top:

• OTC products — over-the-counter, sold without a prescription, but some carry their own rules.
• Prescription (Rx) products — require a valid prescription and a licensed pharmacist’s involvement.
• DEA-scheduled controlled substances — a much stricter regime governed by DEA rules on top of everything else. Treat these as a separate, harder problem.
• Age-restricted items — for example, products containing pseudoephedrine follow logging and quantity-tracking patterns.
• FDA oversight of the drug products themselves.
• Health-data privacy — HIPAA applies to covered entities and their business associates. It is the operator’s obligation, not a checkbox in a shop engine.

To operate lawfully you need state-by-state pharmacy licensure, a licensed pharmacist, and real legal counsel. What software can do is model these distinctions instead of flattening every SKU into “a product.” That modelling is where VBWD’s agnostic-core-plus-plugins architecture earns its place.

Product types: model OTC, Rx, restricted, and scheduled differently

VBWD’s shop uses a product-type registry where a type is an additive cluster of custom fields and workflow hooks. You are not forced into one schema for every item. You define an otc type, an rx type, a restricted_otc type, and (if you ever go there) a controlled type, each carrying only the fields and steps it needs.

• rx can require a prescription reference, a prescriber identifier, and a pharmacist-verification state before the order can ship.
• restricted_otc can require date-of-birth capture and quantity limits.
• otc stays lightweight so ordinary vitamins and first-aid supplies don’t inherit friction they don’t need.

Because types are additive, adding a compliance field to Rx products never touches the OTC catalogue. The range of shop building blocks is on the plugins page.

Geo-blocking: only ship where you hold a licence

State-level access control lets you restrict which shipping destinations a product or the whole store will accept. If your licensure covers a defined set of states, you configure those as the allowed set and orders to other states are refused before payment, not after. This is a technical guardrail against the most common failure mode: selling into a state where you have no standing. It enforces your list; it does not tell you which states you are licensed in. That comes from your licences and your counsel.

Age and identity gating

For age-restricted products you can gate purchase behind date-of-birth or identity-verification steps tied to the product type, so the check fires for the SKUs that need it and stays out of the way for the ones that don’t. The gate is a workflow step you place in the order path; the strength of the identity check depends on the verification method and provider you connect.

Prescription upload and pharmacist verification

An Rx workflow is a product type plus order data plus messaging. A customer ordering an rx item uploads or references a prescription, the order lands in a pending pharmacist review state, a licensed pharmacist reviews it, and only an explicit approval moves it toward fulfilment. Secure messaging between the operator and customer handles clarifications without email sprawl. VBWD gives you the state machine and the data model; the licensed pharmacist doing the review is a human role you must staff, not software.

Audit trail: the event bus and signed webhooks

Regulated selling lives or dies on records. VBWD’s event bus emits domain events across the order lifecycle, and outbound webhooks are signed so a downstream system can verify authenticity. You can stream purchase and verification events to an append-only log or a compliance system of record — for example, the logging pattern behind restricted-OTC sales. The signed, event-driven design is described under features. You still define what to log and how long to retain it; the platform gives you a tamper-evident pipe to send it through.

Pricing, tax, payments, and disclosures

Unified pricing supports per-jurisdiction tax, which matters when health-product taxability varies by state. Payments run through swappable provider adapters, so you can choose processors that will underwrite pharmacy-adjacent merchants rather than being locked to one. The CMS lets you publish the disclosures regulators and customers expect — pharmacist name and credentials, licence information, and terms — as first-class content next to the store.

Data residency and access control for health data

VBWD is self-hosted. The database runs on infrastructure you control, which is a precondition for handling protected health information under a program you can actually audit. Granular access control limits who inside your organization can see order and health-related fields. To be blunt: this supports a HIPAA program, it does not constitute one. VBWD is not “HIPAA-certified,” and no vendor can hand you compliance. The safeguards, the business-associate agreements, the training, and the accountability are yours.

A worked configuration sketch

Say you are licensed to ship Rx items to three states and OTC nationwide. A configuration might look like this:

product_types:
  otc:
    fields: [dosage, active_ingredient]
    ship_states: ALL
  restricted_otc:
    fields: [dosage, active_ingredient, dob_required, unit_quantity_cap]
    verification: [age_gate]
    audit_events: [purchase.logged]
  rx:
    fields: [prescription_ref, prescriber_id, pharmacist_review_state]
    workflow: [pending_review -> approved -> fulfil]
    ship_states: [CA, NY, TX]     # only where you hold licensure
    verification: [identity_check]
    audit_events: [rx.uploaded, rx.reviewed, rx.approved, order.shipped]

webhooks:
  - event: rx.reviewed
    url: https://compliance.internal/log
    signed: true
  - event: purchase.logged
    url: https://compliance.internal/restricted-otc
    signed: true

tax:
  strategy: per_jurisdiction
payments:
  adapters: [processor_a, processor_b]

The list of ship states is a hard technical boundary. The signed webhooks turn every review and restricted sale into a record you can retain and reconcile. None of this decides whether your licences actually cover CA, NY, and TX — that is a legal fact you supply. Integration details and adapter contracts are in the documentation.

Honest limits

Be clear-eyed about what a shop engine cannot do:

• It does not grant pharmacy licensure or replace a licensed pharmacist.
• It does not make you HIPAA-, FDA-, DEA-, or board-compliant. It provides controls a compliance program can use.
• Controlled substances are materially harder. DEA rules go well beyond the patterns above; do not treat scheduled drugs as “just another product type.”
• Identity and age verification are only as strong as the provider and method you wire in.
• Geo-blocking enforces the state list you give it; correctness of that list is on you and your counsel.

Takeaway

Compliance-first commerce means the software’s defaults push toward restriction, verification, and record-keeping instead of maximum throughput. VBWD gives you the technical building blocks — product types that separate OTC from Rx from restricted, state-level geo-blocking, verification gates, a pharmacist-review workflow, a signed audit trail, per-jurisdiction tax, swappable payments, and self-hosted data you control. It is source-available under BSL 1.1 (free until 6.7 BTC/year of attributable sales, converting to Apache-2.0), so you can inspect and run the whole stack yourself. Pair those controls with your licences, your pharmacist, and your lawyers. The platform handles the technical guardrails; the licence to operate is still yours to earn and hold. You can review commercial terms on the billing page.

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

Selling paracetamol online looks, on the surface, like selling anything else: a product page, a cart, a payment button. Then a regulator asks where your prescription verification happens, which member states you ship to, whether your OTC and prescription-only lines are actually distinguishable in the database, and where health-related purchase data physically lives. At that point most general-purpose e-commerce stacks run out of answers.

This article is honest about one thing up front: no software makes a pharmacy compliant. Operating a legally-registered online pharmacy in the EU requires the appropriate national registration and licences, a responsible registered pharmacist, and legal review under your member state’s rules. What a shop engine can do is give you technical building blocks that map cleanly onto those obligations, so the compliance work is a configuration and process exercise rather than a fight with the software. VBWD’s shop engine is built to be that kind of foundation, not a certificate.

Why generic e-commerce fails for pharmacy

Off-the-shelf shop platforms model a “product” as a single flat shape: title, price, image, stock. Pharmacy products are not one shape. An OTC analgesic, a prescription-only antibiotic, and an age-restricted product each carry different mandatory attributes and different rules for who may buy them and from where.

Generic platforms also assume you want to sell to everyone who can reach the URL. Pharmacy is the opposite: EU rules for online medicine sales are national, set per country, so your default posture must be to restrict and then selectively permit. Bolting country logic onto a platform that assumes global reach tends to leave gaps.

Finally, most stacks treat order data as commercial data. A prescription upload, or the fact that someone bought a specific medicine, is health-related data under GDPR and deserves stricter handling than a T-shirt order. The architecture has to respect that from the start.

The building blocks, mapped to EU requirements

VBWD is a self-hosted, source-available platform: Python/Flask, PostgreSQL, Vue 3, Docker, with an agnostic core and everything domain-specific implemented as plugins. Shop, product types, discounts, invoicing, and payments are all plugins on that platform. Below, each capability is paired with the pharmacy obligation it supports.

Product types for OTC, prescription, and restricted lines

The shop engine models a product type as an additive cluster of custom fields registered through a product-type registry. Rather than forcing every product into one schema, you define a type per category and attach only the fields that category needs.

• OTC: standard commercial fields plus active ingredient and pack size.
• Prescription-only: the same, plus a prescription-required flag and fields for the verification workflow.
• Restricted: additional eligibility or age-gating attributes.

This gives you a database-level, queryable distinction between prescription and OTC products — the clear separation regulators expect — instead of a convention that lives only in a category name. You can read more about how the platform composes these clusters in the architecture overview.

Country access control for national rules

Because online-medicine rules differ by member state, jurisdiction control is a first-class need. The platform’s CMS supports country-based access, so you can restrict which markets see and reach given pages and product areas. Combined with a deny-by-default posture, this lets you serve only the countries where you hold the correct registration, rather than exposing your full catalogue to the entire EU and hoping.

Catalogue with a shared filter and pagination contract

The shop catalogue uses a shared filter and pagination contract, so browsing, filtering, and paging behave consistently across product types. In practice this means a customer can filter to only OTC products, or a pharmacist-facing view can filter to prescription lines awaiting verification, using the same predictable mechanism. The consistency matters when you later attach audit and reporting on top of it.

Age and eligibility gating

For age-restricted and eligibility-restricted products, the extra fields on a product type feed gating patterns at the point of sale. The gate is expressed as product data plus order-time checks, which keeps the rule attached to the product rather than hard-coded into a single checkout screen. You still design the exact eligibility policy — the engine gives you the place to attach it.

A prescription-handling workflow

Prescription handling is where the pieces combine. There is no single “prescription” button; instead you compose one from parts you already have:

• A product type flags the line as prescription-required.
• Order data carries the prescription’s state through fulfilment.
• Secure messaging handles uploading a prescription and the pharmacist’s verification exchange, keeping that sensitive material off email.

The registered pharmacist remains the decision-maker. The software’s job is to make sure a prescription-required item cannot progress to fulfilment without the verification step being recorded — a control you configure, not a legal guarantee the platform issues.

An audit trail via the event bus and signed webhooks

Verifiable records are central to pharmacy operations. VBWD’s core emits domain events on an event bus, and you can subscribe outbound signed webhooks to relay those events to an external audit log or an existing pharmacy management system. Because the webhooks are signed, the receiving system can verify authenticity. This gives you an append-only trail of who did what and when, feeding a system of record you control. See the features overview for the event and webhook surface.

Pricing, VAT, and invoicing

Medicines frequently sit under specific or reduced VAT rates that vary by country. The unified price model carries per-line tax so VAT is computed and shown per line item rather than as an opaque total, and the invoicing plugin produces the corresponding documents. That per-line transparency is what makes cross-border VAT handling auditable later.

Self-hosted, EU data residency, and GDPR

Because a purchase of a specific medicine — and any uploaded prescription — is health-related personal data, where that data lives is not a detail. VBWD is self-hosted, so you choose the hosting, including keeping data resident in the EU. There is no obligatory third-party SaaS in the transaction path holding your patients’ health data. This supports GDPR obligations around health data; it does not discharge them. You still need your lawful basis, your retention policy, your data-processing records, and your DPO arrangements where required.

Swappable payment providers

Payments are implemented as swappable adapters, so you can select providers that fit your market and your acquirer relationships rather than being locked to one processor. Details of the payment and billing surface are in the billing documentation.

CMS for mandatory legal pages and the common logo

Legally-operating online pharmacies in the EU must display mandatory information — including registered pharmacist and operator details — and link back from the EU common logo for online medicine sellers to the relevant national register entry. The platform’s CMS is where you author and maintain those legal pages and place the common-logo linkback, keeping the required disclosures under version control alongside the shop.

A worked configuration example

Suppose you are registered to sell OTC medicines in Germany and Austria only, with a prescription workflow for a limited prescription-only range. A rough shape of the configuration looks like this:

product-types:
  otc:
    fields: [active_ingredient, pack_size, vat_rate]
  prescription:
    fields: [active_ingredient, pack_size, vat_rate,
             prescription_required: true,
             prescription_status]      # unverified | verified | rejected
  age_restricted:
    fields: [active_ingredient, pack_size, vat_rate,
             min_age]

country-access:
  default: deny
  allow: [DE, AT]

workflow:
  prescription_required:
    block_fulfilment_until: prescription_status == verified
    channel: secure_messaging          # upload + pharmacist review

audit:
  webhook:
    events: [order.created, prescription.verified,
             prescription.rejected, order.fulfilled]
    signed: true
    target: https://your-pharmacy-system.internal/audit

data:
  hosting: self_hosted
  residency: eu

This is illustrative, not a drop-in file: the exact field names, event names, and options follow the plugin configuration documented in the platform docs. The point is that each obligation — jurisdiction, product distinction, prescription control, audit, residency — has an explicit, reviewable home.

Honest limits

Read this part twice. VBWD is not certified, approved, or endorsed by any medicines regulator, and running your shop on it does not make your pharmacy legal. It gives you technical building blocks; it does not give you a licence.

• You must hold the appropriate national registration and licences for every country you sell into. These rules are national and differ per member state.
• You need a responsible registered pharmacist accountable for dispensing decisions.
• You must obtain independent legal and regulatory review before going live, and keep it current as rules change.
• The platform does not implement Falsified Medicines Directive serialization or verification against national medicines verification systems. Where the FMD context applies to your operation, that is a separate obligation you address with the appropriate systems.
• GDPR compliance for health data is a programme — lawful basis, retention, records, DPO — not a switch the software flips.

None of these are gaps in the software; they are the parts of pharmacy operation that are legal and human by design, and no shop engine should pretend otherwise.

Takeaway

A compliance-ready pharmacy shop is one where every regulatory obligation has a clear technical home: prescription and OTC products are distinct in the data, sales are geo-restricted to the countries you are registered in, prescription verification is a recorded control, health data stays on infrastructure you govern in the EU, and every significant action leaves a signed, auditable trace. VBWD’s shop engine gives you those homes on a self-hosted, source-available platform you can inspect and extend. The licences, the pharmacist, and the legal sign-off remain yours to hold — which is exactly as it should be.

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

You did not go to medical school to spend your evenings fighting a scheduling screen. Yet most clinicians now run their practice on software they do not control: a portal vendor holds the patient list, an appointment tool holds the calendar, a messaging add-on holds the conversations, and each one bills monthly while quietly deciding what you can export. When you want to move, you find out the data was never really yours.

VBWD takes the opposite starting point. It is a self-hosted, source-available platform you run on your own server, assembled from a small agnostic core plus plugins for the parts of practice life you actually use: booking, patient accounts, secure messaging, an on-site chatbot, membership care plans, and a loyalty credit system. This is a practical look at what a clinical day looks like on top of it, and an honest account of what it is and is not.

The problem: rented software, borrowed data

The frustration is rarely one big failure. It is the accumulation of small ones. A booking system that cannot express “I do not take new patients on Fridays.” A patient portal that emails you a CSV instead of an API. A messaging tool that stores threads in a jurisdiction you never chose. And the standing cost of administration: reminders that go out by hand, routine questions that interrupt a consultation, patients who cannot see their own next appointment without phoning reception.

Underneath all of it is lock-in. If the record of who your patients are, when they come, and what you have told them lives on someone else’s infrastructure, your practice is a tenant. VBWD is built so that the practice is the landlord.

Your calendar, your availability

Start with the part of the day you touch most: the schedule. The booking function is a plugin that models your availability, not a generic grid. You define when you see patients, how long each appointment type runs, and where the gaps are. Patients with an account can self-book into the slots you have opened, which removes a large share of the phone-and-callback churn without handing the calendar to a third party.

Because availability is yours to define, the awkward real-world rules fit: buffer time between patients, a hard stop before lunch, blocked mornings for home visits. You are not bending your week to match the tool’s assumptions. The booking and scheduling plugin is one of several you can enable or leave off depending on how your practice runs.

Patient accounts, and the patients who are yours

Every patient can have an account with their own portal: their upcoming appointments, their history with you, their messages. From the clinician side you see your patients — the people who belong to your practice — rather than a slice of some shared vendor pool. Access is governed by granular per-role permissions, so a receptionist, a nurse, and a physician each see exactly what their role warrants and nothing more. That separation matters both for privacy and for the plain question of who is allowed to open what.

The portal also does quiet administrative work. A patient who can see their own next visit, reschedule within your rules, and read a follow-up note is a patient who generates fewer interruptions. Less admin is not a slogan here; it is the direct result of giving patients a controlled window into the data that is already about them.

Secure messaging for follow-ups and results

The messenger is a plugin for secure doctor–patient communication: sending a follow-up, letting someone know results are ready to discuss, answering a logistical question between visits. Because it lives inside the same platform as the accounts and the calendar, a message is attached to a real patient in your practice, not floating in a separate inbox.

Be clear about the boundary. This is general secure communication. It is not a telemedicine system, not a clinical-decision tool, and not a substitute for examining a patient or exercising judgement. “Your results are back, let’s book a call” is what it is for. Diagnosis over chat is not. Keeping that line sharp protects both you and the patient.

A chatbot that only knows your practice

Routine questions are a tax on attention. Where are you located, do you take walk-ins, how do I prepare for this test, what are your hours over the holiday. VBWD includes an LLM-based retrieval chatbot grounded in your own practice content — your pages, your policies, your FAQs — so it answers from what you have actually published rather than from the open internet.

Two design choices are worth understanding. First, the bot rides a search seam that deliberately blocks privacy-sensitive slices of the system. It is built so a general-purpose assistant does not surface patient records; it should be talking about your opening hours, not about anyone’s chart. Second, retrieval runs through an LLM connection manager, so you decide which model backend answers and under what configuration. You can read how the retrieval and permission seams fit together in the platform architecture.

The honest caveat: a language model can be wrong. Keep a human path open. The bot is there to absorb the routine so you are interrupted less, not to be the last word on anything that matters clinically.

Care plans and a reason to come back

Two plugins address the business side of continuity without turning your practice into a storefront. Subscriptions and membership let you offer structured care plans — a recurring wellness membership, a managed-condition programme, a bundle of visits — billed on a schedule you define. For patients who want an ongoing relationship rather than one-off visits, this formalises it.

Alongside that sits a token, or credit, loyalty system. It rewards the behaviours a healthy practice depends on: returning for follow-up, keeping appointments, referring family or friends. Credits accrue and can be recognised in ways you set. It is a modest, optional layer, but for a practice that lives on long-term relationships it gives repeat engagement something concrete behind it. Both sit among the practice functions listed under the platform’s features.

The part that actually matters: you own the data

Here is the structural difference. VBWD is self-hosted. It runs on infrastructure you choose, on a stack of Python and Flask, PostgreSQL, Redis, and a Vue 3 front end, packaged with Docker. If you host it on EU-resident infrastructure, your patient data resides where you put it — data residency by architecture, not by a vendor’s promise. The practice is the data controller. There is no upstream company holding a copy and setting export terms.

The licensing follows the same logic. VBWD is source-available under BSL 1.1: free to run, including commercially, until attributable sales cross a defined threshold, and it converts to Apache-2.0 over time. You can read the source, audit what it does with patient data, and modify it. That is a categorically different relationship than a closed portal where you take the vendor’s word for how records are handled.

Honest limits

Ownership comes with responsibility, and you should hear the boundaries plainly.

• VBWD is not a certified electronic health record and not a medical device. It is a practice platform, not a clinical-records system with regulatory clearance.
• It makes no claim of HIPAA certification or any equivalent. Self-hosting on EU infrastructure gives you data residency and controller status; it does not by itself discharge your regulatory duties.
• Because you are the data controller, the lawful basis for processing, retention policy, consent, and any compliance obligations for clinical records remain your responsibility as the clinician or operator.
• The messenger is general secure communication, not telemedicine. The chatbot can be wrong and must never replace clinical judgement or a human contact route.
• Self-hosting means someone maintains the server, backups, and updates — you, or someone you pay. That is the price of control.

None of this is a reason to avoid the platform. It is a reason to run it with your eyes open, the same way you would adopt any tool that touches patient care. The documentation is the place to work through hosting, roles, and setup before you commit real patients to it.

The takeaway

A clinician’s version of “good software” is quiet: the calendar reflects how you actually work, patients handle their own bookings and see their own history, routine questions get answered before they reach you, follow-ups go out securely, and the record of it all sits on infrastructure you control. VBWD assembles that from parts you can turn on one at a time, on a source-available base you are free to inspect.

It will not sign your compliance paperwork or replace your judgement, and it does not pretend to. What it does is stop your practice from being a tenant in someone else’s system. For a doctor who wants less administration and genuine control over the relationship with each patient, that ownership is the whole point.

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

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