Digital health has a build problem. Every clinic app, patient portal, wellness product, and pharma support tool needs roughly the same skeleton — a secure backend, an AI layer, a web app, iOS and Android, and a way to handle payments and access — and health teams rebuild it from scratch every time, usually while wrestling the hardest constraints in software: privacy, data residency, and compliance. A full-stack framework that ships that skeleton pre-built is worth health innovators’ attention, and VBWD is a notably complete one — with the boundary stated up front: it’s infrastructure, not a medical device, and it doesn’t supply clinical judgement, validation, or regulatory approval.

What “all in the box” means for a health app

VBWD is a constructor for commercial applications, and for health builders the appeal is that “full-stack” is literal:

• A real backend — Python/Flask over PostgreSQL and Redis, with an event system.
• A web frontend — Vue 3, with a patient-facing app and a full admin backoffice.
• iOS and Android — native clients on the same backend, which matters when patients live on their phones.
• An AI layer — a central model-connection manager, retrieval-grounded assistants that answer only from your vetted content, and an agent-callable interface.
• A commercial and access engine — subscriptions, billing, invoicing, access controls, and payments.

The word that matters is one: one backend serving the patient’s phone, the clinician’s browser, and the admin’s dashboard, with one access model deciding who can see what — instead of three subtly different systems and three places for patient data to leak.

The properties health builders actually need

What makes it fit health specifically isn’t a medical feature — it’s the substrate. Because it’s self-hosted and source-available, patient data lives in a database the organisation owns, in a jurisdiction it chooses — the precondition for most health-data compliance, and for patient trust. Its messaging layer is end-to-end-encryptable, with no admin content inspector, so a secure clinician-patient channel is a real option rather than a consumer-app compromise. Its assistants ground answers in your own approved content rather than the open internet. And its search layer is engineered so patient records can’t be surfaced by a misconfigured query. Explore the architecture, the plugins, and the docs to see how these compose.

The same kit across health verticals

Because the core is neutral and each vertical is a plugin, one construction kit builds very different health products: a chronic-disease self-management program with secure check-ins and a vetted-content assistant; a mental-health practice’s encrypted between-session channel with session billing; a pharma patient-support program the sponsor owns end to end; a compliant teledermatology-and-pharmacy storefront; a patient-owned rare-disease registry and community. Different disease areas, different approaches — the same underlying platform, with the domain logic as the part the team actually builds.

The boundary, because it’s health

In healthcare the caveats are the point, not the fine print. A framework can give you a secure, owned, multi-platform foundation for a health application; it cannot give you the clinical validation, the regulatory approval, the compliance program, or the medical judgement that any patient-facing product requires. VBWD provides the infrastructure — the secure backend, the encrypted channel, the grounded assistant, the mobile clients, the billing — and every piece of the actual medicine, and its governance, still has to be built and validated properly on top. It is emphatically not a medical device or a clinical decision system, and no amount of good plumbing changes that.

Why it matters for health innovators

The reason so many good digital-health ideas never ship isn’t a shortage of clinical insight — it’s that building secure, compliant, multi-platform software is expensive and slow, and doing it wrong with patient data is dangerous. A framework that hands you an owned, self-hosted, privacy-respecting, web-plus-mobile foundation — free for commercial use below a defined revenue threshold (see pricing) — lets a health team spend its scarce time on the clinical product and its governance rather than on rebuilding the skeleton. For an industry where the plumbing is unusually hard and the stakes are unusually high, that’s exactly where the leverage is.

General information for healthcare and technology decision-makers, not medical, legal, or regulatory advice. Any patient-facing deployment requires clinical validation, governance, and compliance review appropriate to the jurisdiction. VBWD is infrastructure, not a medical device or clinical system.

There are around 7,000 known rare diseases, and for most of them the single biggest obstacle to a cure isn’t the science — it’s that the patients are scattered, uncounted, and invisible. A condition affecting a few thousand people worldwide has no natural place to gather, no registry, no dataset a researcher can study. The knowledge exists, distributed across isolated families who have never met. The tragedy of rare disease is often a tragedy of fragmentation.

Why registries decide everything

For a rare genetic condition, a patient registry is the foundation everything else is built on. It’s how you learn the natural history of a disease nobody has studied, how you find enough patients to run a trial, how you give a drug company a reason to invest in a treatment for a small population. No registry, no data; no data, no trial; no trial, no therapy. The registry is upstream of hope.

Yet building one is brutally hard for the patient advocacy groups who care most. Commercial registry software is expensive and often means handing the community’s data to a vendor. Academic registries live and die with a grant. And the deepest problem is trust: rare-disease families, who have frequently been failed by institutions, are asked to hand their genetic and medical data to a platform they don’t control, for research they can’t see. Many, understandably, decline — and the fragmentation persists.

A different approach: the community owns the registry

Flip the ownership. Imagine a patient advocacy organisation running its own registry and community on infrastructure it controls. A self-hosted, source-available platform like VBWD makes that structurally possible — with the necessary caveat that it is infrastructure, not research and not medicine: it provides the platform, not the science, the ethics approval, or the clinical validation.

What it does provide fits the need with unusual precision. Self-hosting means the community’s genetic and medical data lives on infrastructure the patient organisation owns — the single most important fact for winning the trust of families who’ve learned to be wary. A secure community and messaging layer lets scattered patients find each other, which for rare disease is itself therapeutic and a recruitment channel. Access controls govern precisely who can see what. And a dataset layer means that when the community chooses to share data with a legitimate researcher, it can do so on its own terms — governed, consented, and revocable — rather than surrendering it wholesale. The plugins and architecture show how the data and community pieces compose; the platform is source-available and free to run below a defined revenue threshold, which matters when the operator is a small advocacy group rather than a funded company.

Patient-owned data as the unlock

The quiet revolution here is consent that patients actually control. In the standard model, a patient signs their data away once and loses sight of it. In a community-owned registry, the organisation and its members hold the data, decide which research to support, and can share a governed dataset with a pharma partner or academic group as a deliberate, revocable act. That reframes the relationship: patients stop being subjects to be harvested and become stewards of an asset that might fund their own cure. For populations repeatedly failed by institutions, ownership is what makes participation feel safe enough to happen at all.

The boundary

Precision matters even in an optimistic piece. A registry platform is not a clinical trial, an ethics committee, or a guarantee of research quality — those require institutional review, informed consent frameworks, data-protection compliance, and scientific rigour that no software supplies. Owning the infrastructure removes the trust and cost barriers to gathering the data; the responsible science still has to be done properly on top of it, and rare-disease data is especially sensitive precisely because small populations are easier to re-identify.

Why it matters

For rare disease, the bottleneck is almost always that the patients can’t be found and their data can’t be pooled — and that’s a fragmentation and trust problem as much as a scientific one. Self-hosted, source-available infrastructure lets the people with the most at stake own the registry, hold the data, find each other, and choose how their information advances research. It won’t discover a therapy. But it can build the trusted, community-owned foundation without which the therapy never gets studied at all — and for 7,000 diseases waiting to be counted, that foundation is the thing standing between invisibility and a chance.

General information for patient organisations, researchers, and technology decision-makers, not medical, legal, or research-governance advice. Patient registries and data sharing require ethics approval, informed consent, and data-protection compliance appropriate to the jurisdiction. VBWD is infrastructure, not a research platform, clinical system, or medical device.

Explore VBWD

VBWD is a self-hosted, source-available platform for building secure, data-owned applications — used here as infrastructure, never as a medical device. Learn more:

• Platform and docs: vbwd.cc — the plugins, the architecture, the developer docs, and pricing.
• Source on GitHub: github.com/VBWD-platform
• See it running: demo video · LinkedIn

Free for commercial use while VBWD-attributable sales stay under the value of 6.7 BTC a year.

Teledermatology is one of medicine’s genuine digital success stories — a photo of a rash, a specialist opinion, a prescription, all without a waiting room. But behind the tidy patient experience sits a mess: the consultation runs on one system, the prescription on another, the pharmacy fulfilment on a third, and compliance with pharmacy law is stitched across all of them by hope. Skin conditions are common, chronic, and image-friendly, which makes dermatology the perfect place to see both the promise and the plumbing problem.

The compliance sprawl problem

Selling regulated products — prescription dermatology treatments, restricted-strength topicals, even some cosmeceuticals — is not e-commerce with extra steps. It’s a regulated activity with real obligations that differ by jurisdiction: prescription verification, pharmacist oversight, age and identity checks, record-keeping, and rules about what can be sold to whom and where. In the EU and US these differ enough that “just use a standard online store” quietly becomes non-compliant the moment a real prescription is involved.

So dermatology-and-pharmacy operators end up bolting a subscription plugin here, a compliance module there, a webhook to a pharmacy system, and a separate teledermatology tool on top — a fragile stack where the storefront doesn’t know what the consultation knows, and neither fully owns the patient relationship.

A different approach: one platform, compliance built in

The alternative is a platform where the storefront, the consultation channel, and the compliance rules live in the same system. A self-hosted, source-available platform like VBWD is designed around exactly that kind of composition — with the standing caveat that it is commerce-and-communications infrastructure, not a medical device, and the clinical judgement always belongs to the prescriber.

The pieces line up. A shop engine with configurable product types can model the difference between an over-the-counter moisturiser and a prescription-gated treatment, applying the right checks to each. A secure messaging and image channel carries the teledermatology consultation — a photo of the affected skin, the clinician’s response — on infrastructure the operator controls rather than a consumer app. Access controls and gated products enforce who can buy what. Subscription billing handles the repeat-prescription model that chronic skin conditions naturally fit. And provider-agnostic payments, including regional processors, keep the checkout working across the jurisdictions the compliance rules already differ across. The plugin catalogue and pricing page show how the commerce pieces assemble.

The compliance reality check

Here is the line that matters, because pharmacy is heavily regulated and overclaiming is dangerous. A platform can enforce rules you configure — gate a product behind a prescription, require an identity check, keep the records — but it cannot decide what your legal obligations are, and it is not itself a licensed pharmacy or a compliance guarantee. The prescriber prescribes; the pharmacist oversees; the operator holds the licences and the legal responsibility. Software makes a compliant workflow easier to build and harder to accidentally break. It does not replace the pharmacist, the prescriber, or the regulatory approval — and any dermatology-plus-pharmacy deployment needs proper legal and pharmacy sign-off before it touches a real patient.

Why it matters

The teledermatology experience is good; the infrastructure under it is usually a compliance liability waiting to surface. Consolidating the storefront, the consultation, and the rule-enforcement into one self-hosted platform the operator owns turns a fragile multi-vendor stack into a single system with the patient data and the compliance logic under one roof. For a field as image-driven and prescription-heavy as dermatology, that’s the difference between a demo that impresses and a service that survives an audit. VBWD is free for commercial use below a defined revenue threshold, making owned, compliant infrastructure reachable for the independent pharmacies and clinics that need it most.

General information for pharmacy, dermatology, and technology decision-makers, not medical, legal, pharmaceutical, or regulatory advice. Selling regulated products and delivering telemedicine carry jurisdiction-specific legal obligations; obtain qualified legal and pharmacy review before deployment. VBWD is infrastructure, not a licensed pharmacy or a medical device.

Explore VBWD

VBWD is a self-hosted, source-available platform for building secure, data-owned applications — used here as infrastructure, never as a medical device. Learn more:

• Platform and docs: vbwd.cc — the plugins, the architecture, the developer docs, and pricing.
• Source on GitHub: github.com/VBWD-platform
• See it running: demo video · LinkedIn

Free for commercial use while VBWD-attributable sales stay under the value of 6.7 BTC a year.

A patient tells their therapist things they’ve never told anyone. Then, between sessions, they message that therapist about a hard night — and the message travels through a consumer app, sits on a third party’s servers, and is, in a very real sense, no longer private. For every other kind of medical data this is bad. For mental health, where the stigma is the illness’s cruelest feature, it can be catastrophic.

Why privacy is the treatment, not a feature

In depression, anxiety, and every psychiatric condition, confidentiality isn’t an administrative nicety — it’s a precondition for the therapy working at all. People don’t disclose what they fear will leak. A patient who suspects their therapy messages could surface — in a breach, a subpoena, an app’s data-sharing policy — will hold back, and holding back is the opposite of treatment. The privacy is the clinical container.

Yet async messaging between sessions is enormously valuable in mental health. The gap between weekly appointments is long, and a supported check-in during a bad stretch can matter more than the session itself. So clinicians face a bind: the between-session channel patients need runs on infrastructure that undermines the confidentiality the treatment depends on.

A different approach: confidentiality by architecture

The resolution is to make privacy structural rather than promised. This is where a self-hosted platform with genuine end-to-end encryption changes the equation — and, as always in a clinical context, the boundary first: VBWD is infrastructure, not therapy. It is not a treatment, not a diagnostic tool, and not a replacement for a clinician. What it offers is a communication layer whose privacy is enforced by design.

The relevant properties are specific. With its end-to-end encryption layer, the server holds no keys and never decrypts — clients encrypt, and the server only stores and relays sealed envelopes. A practice’s own administrator cannot read a therapy exchange; neither can the host, nor anyone who obtains the database. There is no admin content inspector anywhere in the system — not a permission that’s switched off, but a feature that doesn’t exist, so no one can be pressured into reading what they structurally cannot. Retention is short by default and set by the practice, so sensitive exchanges aren’t hoarded. And it’s self-hosted, so the data lives in a jurisdiction the practice chooses. The developer documentation and architecture pages lay out how the encryption and messaging seams work.

Add subscription billing for session packages and the practice has a sustainable async-care offering that doesn’t compromise the one thing psychiatric care can’t compromise.

The hard limits — read these

Mental health demands the most careful boundaries of any specialty, so several must be explicit. This is text and images, not a crisis service — an encrypted messaging channel is categorically not a suicide hotline or emergency response, and any deployment must route acute risk to real crisis pathways loudly and immediately. It is not an AI therapist; automated responses have no place in delivering psychiatric care, and the value here is secure human-to-human communication, not a bot pretending to counsel. And confidentiality has a legal ceiling — mandatory-reporting and duty-to-warn obligations still apply, and a system must be designed around them, not in denial of them.

Why it matters

Mental health care is being delivered digitally whether the infrastructure is ready or not, and too much of it runs on consumer tools that quietly betray the confidentiality the treatment requires. A self-hosted, end-to-end encrypted platform lets a practice offer between-session support where privacy is guaranteed by mathematics rather than a policy page — with crisis escalation and clinical judgement kept firmly human. In the one field where a privacy breach can undo the treatment itself, building on infrastructure that provably can’t read the conversation isn’t a luxury. It’s the standard of care catching up to the technology.

General information for mental-health and technology decision-makers, not medical, legal, or clinical advice. Digital mental-health tools require clinical governance, crisis-safety design, and compliance review appropriate to the jurisdiction. VBWD is infrastructure, not a therapeutic or diagnostic service.

Explore VBWD

VBWD is a self-hosted, source-available platform for building secure, data-owned applications — used here as infrastructure, never as a medical device. Learn more:

• Platform and docs: vbwd.cc — the plugins, the architecture, the developer docs, and pricing.
• Source on GitHub: github.com/VBWD-platform
• See it running: demo video · LinkedIn

Free for commercial use while VBWD-attributable sales stay under the value of 6.7 BTC a year.

When a pharmaceutical company launches an oncology therapy, it doesn’t just ship a drug — it ships a promise to help patients stay on it. These patient support programs handle side-effect reporting, adherence coaching, financial navigation, and the endless questions a frightened cancer patient has. Almost always, the pharma company outsources the whole thing to a third-party vendor. And almost always, that means handing over the most sensitive data imaginable to a company it doesn’t control.

The patient support program problem

Oncology is where patient support programs matter most and cost most. The therapies are complex, the side effects are serious, and adherence is fragile precisely when it’s most important. A good program measurably improves persistence on therapy. But the standard model has a structural flaw: the manufacturer, the specialty pharmacy, and the third-party program vendor each hold a slice of the patient’s data, none of them owns the whole relationship, and the patient’s cancer information flows through systems the sponsor can neither see into nor fully secure.

When a data breach happens — and in this vendor-sprawl model it eventually does — it’s oncology patients’ records that leak, and the sponsor’s name in the headline.

A different approach: own the program

Now imagine the sponsor or specialty pharmacy running the support program on infrastructure it owns. A self-hosted, source-available platform like VBWD is built for exactly this shape of problem — with the essential caveat, stated up front, that it is infrastructure, not medicine: not a diagnostic system, not a clinical decision tool, and not a substitute for the oncology team.

What it does provide is the operational spine of a program. A secure, end-to-end-encryptable channel for patients to report side effects and ask questions, where the conversation lives on the sponsor’s own servers rather than a vendor’s. A grounded assistant that answers logistics and education questions — how to store the medication, what to do about a missed dose, where to find financial assistance — from the program’s own approved content. Access controls that gate who on the care team sees what, with a search layer engineered so patient records can’t be surfaced by a misconfigured query. And data ownership: the program’s data stays in one place the sponsor controls, instead of scattered across three vendors. Explore the architecture and the developer docs to see how the access and messaging layers fit together.

The pharmacovigilance angle

There’s a regulatory bonus hiding here. Oncology programs carry a duty to capture and report adverse events. A secure channel the sponsor owns, feeding a database the sponsor controls, is a cleaner path to reliable adverse-event capture than a fragmented vendor chain where reports can fall between systems. Owning the infrastructure makes the compliance obligation easier to meet, not harder — provided the pharmacovigilance workflow itself is built and validated properly on top of it.

The boundary

The line is non-negotiable in oncology. A program assistant handling logistics, education, and structured side-effect intake is a support tool. Triaging whether a reported symptom is a medical emergency, or advising on dose changes, is clinical work that belongs to the oncology team, full stop. Owning the platform improves security, data control, and adverse-event capture; it does not and must not replace the clinical judgement that oncology demands.

Why it matters

The current model asks pharma companies to run their most sensitive patient relationships on infrastructure they don’t own, then holds them accountable when it leaks. Self-hosted, source-available infrastructure offers the alternative: keep the program, the data, and the patient relationship under one roof you control. VBWD is free for commercial use below a defined revenue threshold, which makes owning the stack a realistic option rather than a nine-figure build. In oncology, where the data is this sensitive and the stakes this high, ownership isn’t a preference — it’s risk management.

General information for pharma and healthcare decision-makers, not medical, legal, or regulatory advice. Patient support and pharmacovigilance systems require rigorous validation, governance, and compliance review. VBWD is infrastructure, not a medical device or clinical decision system.

Explore VBWD

VBWD is a self-hosted, source-available platform for building secure, data-owned applications — used here as infrastructure, never as a medical device. Learn more:

• Platform and docs: vbwd.cc — the plugins, the architecture, the developer docs, and pricing.
• Source on GitHub: github.com/VBWD-platform
• See it running: demo video · LinkedIn

Free for commercial use while VBWD-attributable sales stay under the value of 6.7 BTC a year.

The hardest part of managing type 2 diabetes isn’t the medicine. It’s the 8,760 hours a year the patient spends away from the clinic, making small decisions alone — what to eat, whether to take the dose, whether that number on the meter is worth a call. Adherence quietly decides outcomes, and adherence happens in the gaps between appointments, where most healthcare software simply isn’t.

The gap nobody staffs

A person newly diagnosed leaves the consultation with a plan and a pamphlet. Two weeks later they have a question at 9pm that isn’t urgent enough for the emergency line and won’t wait three months for the next appointment. So they Google it, or ask a general chatbot, or guess. Multiply that by every patient and every small decision, and the gap between visits is where good plans quietly fail.

Clinics know this. The answer — structured, between-visit support: check-ins, reminders, a trusted place to ask — is well understood. What’s missing is affordable infrastructure to run it without shipping patients’ diabetes data to a third-party app nobody vetted.

A different approach: the program as software you own

Consider a structured self-management program built on infrastructure the clinic controls. This is where a self-hosted platform like VBWD becomes relevant — and precision matters here, so plainly: VBWD is infrastructure, not medicine. It is not a diagnostic tool and does not replace a clinician. What it provides is the delivery layer for a program a care team designs.

The pieces map neatly onto the need. A secure messaging channel (self-hosted, end-to-end encryptable) lets a patient ask that 9pm question and a nurse answer it the next morning, without the conversation living on a consumer app. A grounded assistant answers routine questions — “should I take my metformin with food?” — from the clinic’s own vetted content, not the open internet, so the guidance is the clinic’s, not a model’s guess. Subscription billing turns the program into a sustainable service line rather than unpaid labour. And because it’s self-hosted, the diabetes data — arguably some of the most sensitive a person has — stays in the clinic’s own database, in its own jurisdiction. You can see how these pieces compose in the plugin catalogue and the architecture overview.

The boundary that keeps it safe

The line has to be bright, because diabetes self-management is exactly where a careless tool does harm. A between-visit assistant answering “here’s what our clinic advises about carbohydrates” and “here’s when to call us” is an education-and-logistics tool, and a genuinely useful one. An assistant deciding whether a specific reading means a specific patient should change insulin is a clinical act, and no amount of good infrastructure turns it into one. Grounding and self-hosting improve privacy and consistency; they do not confer clinical judgement, and the program must be designed so a human always holds the decisions that matter.

Why it changes the economics

The reason clinics don’t already run programs like this isn’t ignorance — it’s cost. Custom patient-engagement software is expensive, and the off-the-shelf options often mean handing patient data and the customer relationship to a vendor. A self-hosted, source-available platform inverts both problems: the clinic owns the software and the data, and stands up the program in weeks rather than commissioning a build. For a chronic condition managed mostly at home, closing the between-visit gap affordably isn’t a nice-to-have — it’s where the outcomes actually live.

General information for healthcare decision-makers, not medical, legal, or regulatory advice. Any patient-facing deployment requires clinical validation, governance, and compliance review appropriate to the jurisdiction. VBWD is infrastructure, not a medical device.

Explore VBWD

VBWD is a self-hosted, source-available platform for building secure, data-owned applications — used here as infrastructure, never as a medical device. Learn more:

• Platform and docs: vbwd.cc — the plugins, the architecture, the developer docs, and pricing.
• Source on GitHub: github.com/VBWD-platform
• See it running: demo video · LinkedIn

Free for commercial use while VBWD-attributable sales stay under the value of 6.7 BTC a year.

Data is a product — if you can collect it, package it, and charge for it

Plenty of businesses sit on, or near, valuable data — pricing trends, environmental readings, market shares, regional statistics — and never turn it into revenue, because the path from “we could gather this” to “customers pay us for it monthly” is a stack of unglamorous engineering: collection, cleaning, versioning, delivery, access control, and billing. VBWD splits that path into two focused pieces — datavibes for producing datasets and the dataset plugin for selling them — so you can run a data product without building the plumbing from scratch.

datavibes: the data generator

datavibes is a config-driven toolkit whose single job is to produce datasets. It pulls data from public sources, normalises and derives it, and emits a ready-made, versioned dataset — timestamped snapshots you can hand to anything downstream. It is deliberately simple: no web server, no database, no billing inside it. Given a dataset’s configuration and a point in time, it produces the same dataset every time. That determinism is the point — a data product people pay for has to be reproducible, not a one-off scrape that no one can regenerate.

Each dataset is defined declaratively: a small configuration plus, where needed, a tiny adapter for its specific source. You run it two ways from one codebase. As a command you schedule — a cron job (for example, a GitHub Action) runs it on an interval and captures the fresh snapshot — or as a library another Python program imports to drive the same pipeline in-process. The result is a growing series of clean, dated snapshots for each dataset: the raw material of a data business.

Inside VBWD this shows up as a Data Generator admin panel. You manage profiles — each a named dataset with a slug, title, category, row count, and its latest snapshot — and you manage their schedules with cron expressions: enable or disable a profile, see its last run and next fire time, check whether the last run succeeded, or trigger a run on demand. In other words, the collection side becomes an operational surface you watch and control, not a pile of scripts you hope still work.

The dataset plugin: the storefront and the delivery

Producing snapshots is half the business; the other half is selling access to them, and that is what the dataset plugin does. It consumes the files datavibes produces and turns each dataset into something you can monetise. A dataset is modelled as a priceable item: a customer buys it, the purchase grants an entitlement, and the entitlement unlocks API access to the data. The billing, tax, and invoicing all run through VBWD’s unified pricing and subscription engine, so a dataset is sold with the same machinery as any other product on the platform — one-off, or on a recurring subscription for continuously-updated data.

Just as important for actually getting customers: every dataset can carry its own SEO metadata and get its own indexable landing page. Instead of one generic “datasets” page, each dataset has a real URL that describes what it contains and can rank in search — so buyers discover the specific dataset they need. Because VBWD serves crawlable pages for its single-page frontend, those per-dataset pages are visible to search engines, not just to logged-in users.

How the two fit together

The division of labour is clean, and it is what makes the whole thing maintainable:

• datavibes collects and generates — on a schedule, deterministically — and emits versioned snapshots. It knows nothing about money.
• the dataset plugin catalogues those snapshots, gates them behind entitlements, serves them over an API, gives each one a sellable page, and handles the billing.
• the rest of VBWD — accounts, subscriptions, invoices, the agnostic plugin core — carries everything around them.

You can run either half on its own. Use datavibes purely internally to feed your own dashboards, reports, or AI assistants; or use the dataset plugin to sell data you already have. Together, they are a self-hosted “data product” business: collect on a schedule, publish snapshots, sell API access, and let each dataset earn its own search traffic.

Business models this unlocks

The same two pieces support several ways to make money, and you can mix them:

• Subscription data feeds. A dataset that refreshes on a schedule is a natural subscription: customers pay monthly for continuous access to the latest snapshots via the API. Recurring revenue from something a cron job maintains.
• One-off dataset sales. For point-in-time data — a full historical archive, a specific snapshot — sell it once with entitlement-gated download or API access.
• Freemium and samples. Publish a small or delayed snapshot free to rank in search and prove value, and gate the full resolution, full history, or real-time feed behind payment. The free sample is your marketing; the entitlement is your paywall.
• Data-as-an-API. Because access is delivered through an API keyed to an entitlement, your buyers are developers integrating your data into their own products — a higher-value, stickier customer than a one-time download.
• Vertical data products. Curate datasets for a specific audience — environmental and air-quality readings for a wellness or property brand, energy and renewable-share figures for a sustainability consultancy, regional weather or mobility statistics for a logistics tool. A focused, well-maintained vertical dataset beats a generic dump.
• Internal leverage. Even with nothing for sale, feeding clean, versioned data into your own analytics and reporting removes a recurring manual chore and makes your numbers reproducible.

A worked example

Say you want to sell an environmental dataset — air-quality readings by region. You define a datavibes profile that pulls from the public source, normalises it into a consistent schema, and derives the fields you care about. You schedule it to run daily, so each morning a new timestamped snapshot lands. In the dataset plugin you publish that profile as a product: a monthly subscription for API access to the latest data, plus a one-off price for the full historical archive. You give it an SEO page describing exactly what it covers, so a business searching for regional air-quality data finds your page and subscribes. From then on, the cron job maintains the product and the platform handles discovery, entitlement, delivery, and billing. Your ongoing work is curation and quality, not plumbing.

The honest limits

A data business has real responsibilities the software cannot discharge for you. First, rights: datavibes pulls from public sources, but “public” is not the same as “free to redistribute or resell” — you are responsible for confirming you have the right to package and sell any derived dataset, and for respecting each source’s terms and licence. Second, quality and liability: determinism means datavibes reproduces a dataset faithfully, but if the upstream source is wrong or changes shape, your dataset inherits that — you own data quality, documentation, and any accuracy claims you make to customers. Third, operations: this is self-hosted, so you run the schedules, storage, and API, and you own uptime and backups. What the platform gives you is the technical path from collection to paid API; the editorial judgement, the source licences, and the trust you build with buyers are yours.

Takeaway

Turning data into a product usually stalls on engineering no one wants to build. VBWD removes that blocker by separating the job cleanly: datavibes produces versioned datasets on a schedule, deterministically, from simple configuration; the dataset plugin catalogues them, gates them behind entitlements, serves them over an API, and gives each one a sellable, searchable page — all billed through the platform’s subscription engine, all self-hosted, all yours. If your business sits near data worth paying for, the path from “we could collect this” to “customers subscribe to it” is now a configuration and a cron schedule, not a project.

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 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

Your studio runs on relationships. Someone books a first yoga class, comes back for a workshop, buys a ten-pass, brings a friend, becomes a regular. That whole arc lives in your booking app, your inbox, a spreadsheet, and your head. And when you use a marketplace to get discovered, the platform sits in the middle of every one of those touchpoints, takes a cut, and quietly owns the client relationship you built.

This piece is about a different setup: running bookings, memberships, messaging, and a loyalty programme on software you host yourself. The tool is VBWD, a source-available, self-hosted client-management platform. It is warmer to your margins and stricter about who owns the data. Here is what it does for a wellness business and where it stops.

The problem: you rent your own client list

Most studios stitch together three or four services. A booking app for the calendar. A separate mailing tool. A payment processor. Maybe a loyalty punch-card app on top. Each one holds a slice of your client data, and none of them are really yours.

The booking marketplaces are the sharpest version of this. They bring you visibility, then charge a per-booking fee or a monthly rent, and the client’s account, reviews, and rebooking habit live on their platform, not yours. If you leave, the relationship often does not come with you. You are renting access to people who came to see you.

There is also a quieter cost: client data. Health notes, injury history, therapy context, contact details. That information sits on servers in jurisdictions you did not choose, under privacy terms you did not write.

What VBWD gives a wellness studio

VBWD is an agnostic core with a set of plugins you switch on for the functions you need. You do not have to run all of it. Here is the part that matters for a spa, studio, or practice.

Bookings and self-scheduling

The booking function handles the calendar work: classes with capacity, one-to-one sessions, staff or room availability, and a self-booking flow so clients reserve their own slots without messaging you. A pilates studio can publish a weekly class grid; a massage therapist can expose only the openings they want filled. Clients book, get confirmations, and manage their own reservations from an account on your site.

Because it is your install, the booking page carries your brand, your terms, and your prices, with no marketplace badge and no per-booking fee skimmed off the top.

Client accounts and portals

Every client gets an account on your platform. They see their upcoming sessions, past visits, active memberships or passes, invoices, and messages in one place. For the studio, that account is the single record of a client’s history, and it lives in your database, not a vendor’s.

This is the core of the ownership argument: the client list, with everyone’s booking history and preferences, is a table in your PostgreSQL database that you can back up, export, and query however you like.

A secure messenger for client communication

Wellness conversations are personal. A therapy client cancelling a session, a spa guest asking about a treatment before a birthday, a coaching client checking in between calls. VBWD includes a built-in messenger so those exchanges happen inside your platform instead of scattered across personal WhatsApp threads and email.

Keeping messages on your own install matters when the content is health-adjacent. You decide retention, you decide who on your team can read what, and nothing rides through a third-party chat product.

An AI chatbot grounded in your own content

VBWD can run a retrieval-augmented (RAG) chatbot that answers from your studio’s own material, your pricing, your class descriptions, your FAQ, your policies, rather than making things up from the open internet. A visitor at 11pm can ask “do you have a prenatal yoga class on Saturdays and how much is a five-pack?” and get an answer drawn from your actual content, plus a nudge into the booking flow.

Technically, the bot rides a search seam that deliberately blocks the private slices of your data (it will not read a client’s therapy notes or invoices), and it talks to language models through a connection manager so you choose the provider. It is a front-desk assistant for the questions you answer twenty times a week, not a window into confidential records. You can see the full set of switch-on functions on the plugins page.

Memberships and class passes

The subscription function covers recurring wellness revenue: monthly memberships, unlimited-class plans, ten-session passes, treatment bundles. VBWD handles the recurring billing, generates invoices with tax, and supports multiple currencies, which helps if you run retreats or serve clients across borders. Billing details and how the money side is structured are laid out on the billing page.

Memberships tie back into bookings and accounts, so a member’s pass balance and renewal date sit in the same client record as their session history.

A loyalty programme built on tokens you own

VBWD has a token, or credit, system, and for a wellness business the natural use is loyalty. You define how clients earn credits (points for each visit, a bonus for referring a friend, a reward for hitting a streak) and what they redeem them for (a free class, a treatment upgrade, a discount, a small perk).

Because you configure the rules, the programme fits your studio rather than a generic punch-card template. The same token mechanism can also meter usage-based extras, for example AI or premium content, but for most studios it is simply a loyalty ledger you control end to end.

The ownership and privacy angle

The through-line across all of this is that there is no platform in the middle. No per-transaction cut on bookings or memberships. No marketplace that owns your reviews and rebooking habit. The client list, the message history, the loyalty balances, they are rows in a database you run.

VBWD is self-hosted, which means you can keep it on EU infrastructure for data-residency reasons if that matters to your clients, and it is source-available under BSL 1.1: free to use commercially until your VBWD-attributable sales pass a defined threshold (6.7 BTC per year), and the licence converts to Apache-2.0 over time. It is not public-domain, but it is software you can read, adapt, and self-host without asking permission for normal use.

Under the hood it is a fairly standard stack, Python/Flask, PostgreSQL, Redis, a Vue 3/TypeScript frontend, all in Docker, and one backend serves both your website and a native mobile app. The technical detail lives in the documentation.

The honest limits

Self-hosting means you operate it. Uptime, backups, and updates are on you or whoever you pay to run the box. If your studio does not want to touch servers, budget for a technical partner, because a booking system that is down on a Monday morning is a real problem.

The AI chatbot can be wrong. It is grounded in your content, which reduces invented answers, but you should treat it as a helpful front desk, not an authority on medical or therapeutic questions, and keep a human path for anything sensitive.

The loyalty tokens are a credit system you configure, not a regulated financial instrument. They are studio points, not money, and you should describe them to clients that way.

Takeaway

If your studio is small and you just need a calendar, a marketplace app is faster to start. But if the client relationship is the business, and in wellness it usually is, then owning the bookings, the accounts, the messages, the memberships, and the loyalty programme is worth the operational effort. VBWD is one way to run all of that on infrastructure you control, without a platform taking a slice of every visit. Start with the feature overview and turn on only the functions your practice actually needs.

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