Plans & Subscriptions

How RestartiX makes money from clinics, and how clinics make money from patients on the platform. The commercial model in plain terms.

---

The two-sided model

Money flows on two distinct levels:

Level	Who pays	Who collects	What it pays for
Platform plan	The clinic	RestartiX	Access to the platform — features, capacity, support
Patient tier	The patient	The clinic	Access to the clinic's own services — premium care, telerehab, priority booking

These two layers are independent by design. The platform plan determines what tools and limits the clinic has available. Within those limits, the clinic decides how to package and price its own offering to patients.

Note

"Plans" in this document refers to the platform's commercial tiers (Free / Pro / White-Label) and the clinic-defined patient tiers (Basic / Premium). It is not the same as service plans — multi-session therapy packages clinics sell to patients (e.g., "10-session physiotherapy package"). Those are documented under Service Catalog. Two different things, both legitimately called "plans."

---

Platform Plans (clinics → RestartiX)

What RestartiX sells to clinics. Three building blocks, mixed and matched.

Base plans

The clinic's primary subscription. Sets the foundation: what features are unlocked, how many patients/specialists are allowed, what level of support comes with the relationship.

The catalog ships with three illustrative tiers — actual names and prices are configurable, not hardcoded:

Tier	Aimed at	Includes (examples)	Limits (examples)
Free	Trial, single-practitioner	Booking, patient records, basic forms	50 patients, 1 specialist, no custom domain
Pro	Established clinics	+ Custom domain, automations, webhooks, document templates	1,000 patients, 10 specialists, 50 GB storage
White-Label	Clinics demanding full brand isolation; sales-negotiated	+ Priority support, custom limits, no platform attribution, dedicated auth-provider tenant	Negotiated per contract

The White-Label plan tier is the customer-facing name for the tenant-isolation deployment mode — the clinic's brand is the only counterparty patients see, with a dedicated identity namespace and clean exit on contract termination. Both Free + Pro plans run on the shared (named-tech) deployment mode; White-Label runs on tenant-isolation. Hospital networks and dedicated-infrastructure tiers are permanently out of scope (see CLAUDE.md → Project Overview).

Clinical features (telerehab, video consultations, camera-based measurements) are gated separately — see The medical features question.

Multi-location is foundational across all tiers

Multi-location is a platform foundation primitive (Layer 1B.14, see foundation.md) — every clinic on every tier may operate multiple physical locations. The number of locations included per tier (and any per-location pricing) is a plan limit in the catalog, not a capability gate. Multi-location is not gated to White-Label.

Add-ons

Stack on top of the base plan. The clinic keeps their base plan and adds capabilities they specifically need.

Examples: Telerehab Pack (unlocks treatment plans + exercise prescription), Video Pack (unlocks integrated video consultations), Branding Pack (unlocks custom-domain and brand customization on shared-mode plans, without going to full White-Label).

A clinic on Pro + Telerehab Pack pays for both, gets both, and can drop the add-on without touching the base plan.

Usage packs

One-time purchases that increase a specific capacity. Useful for spiky usage that doesn't justify a tier upgrade.

Examples: +1,000 video minutes (added to current month), +10 GB storage, +500 patient slots.

Usage packs add to the running meter for a billing period or until consumed. They're additive, not replacements.

How a clinic's bill is composed

Pro base plan         RON  490 / month
Telerehab Pack        RON  290 / month
Video minutes pack    RON   80 / one-time (this month)
                      ──────────────
                      RON  860 this month

Internally the platform supports any combination. The illustrative pricing above is for explanation only — actual price points are decided commercially and updated through the catalog, not through code.

---

Patient Tiers (patients → clinic)

Each clinic defines its own tier catalog. The platform doesn't impose a tier shape — every clinic decides how (or whether) to segment its patients commercially.

Examples of how clinics might use tiers

Clinic style	Tier 1	Tier 2	Tier 3
Sports physiotherapy	Standard care	Premium (priority booking, faster reports)	—
Telerehab-first	Free assessment	Monthly subscription (treatment plans + library)	—
Multi-specialty	Walk-in patient	Membership (discounted services + telerehab)	Corporate plan (employer-sponsored)
Single practitioner	(no tiers — everyone is a patient)	—	—

A clinic can have one tier (everyone equal), two tiers (free / premium), or many. Names, prices, and what each unlocks are entirely the clinic's call.

What a tier can include

A tier does two things at once. It assigns the patient a role (which determines what they can do — book directly, access the library, see specific document types), and it can also bundle counted entitlements (a set number of services included, regenerating per period).

The role part is unbounded by quotas — "Premium patients can self-assign treatment plans" applies to as many treatment plans as the patient wants, gated only by RBAC. The counted-entitlement part is for things the clinic wants to meter — "4 free consultations included with the annual subscription," "4 specialist-assigned treatment plans per year," "10% discount on the next 5 appointments." A tier can mix both freely.

Two policy defaults are baked in, overridable per inclusion when a clinic needs different behavior:

• Use-it-or-lose-it on renewal. When the year rolls over and the patient hasn't used all 4 consultations, the leftover doesn't carry. Cleanest accounting; matches what most patients expect from "X per year" language.
• Full grant on upgrade. When a patient upgrades from Basic to Premium mid-year, they receive the full 4 consultations, not pro-rated. Standard sales-lever practice; encourages mid-cycle upgrades.

Example: Annual Premium

A telerehab-first clinic on Pro + Telerehab Pack defines:

Tier	Role	Counted inclusions
Free	Read-only patient access	None
Annual Premium (200 RON / month)	Library access + self-assignment	4 consultations / year + 4 specialist-assigned treatment plans / year

When Maria signs up for Annual Premium:

• She gets the Premium role immediately — can self-assign from the exercise library, see specialist contact info, access the telerehab portal.
• The platform automatically grants her two service plan enrollments — 4 consultation sessions and 4 specialist treatment-plan assignments. Each tracks usage.
• When Maria books a consultation, the platform decrements the counter automatically. Same booking flow as a directly-purchased package.
• A year later, the period rolls over — leftover sessions drop, fresh 4+4 are granted for the new period.
• If Maria upgrades to a hypothetical higher tier mid-period, her old inclusions expire and the new tier's full inclusions are granted.

The clinic doesn't write any code or run any cron jobs. It defines the catalog ("here are the tiers we offer, here's what each includes") and the platform handles lifecycle: provisioning on signup, decrementing on consumption, expiring on cancel, regranting on renewal.

What changes when a patient moves between tiers

Each tier is mapped to a role inside the clinic. Roles determine what the patient can do — book directly with specialists, access the telerehab library, see specific document types, etc.

When a patient's tier changes (the clinic flips them from Basic to Premium), the platform automatically updates their permissions. The clinic doesn't manage permissions per patient — it manages tiers, and the platform handles the rest.

This means the clinic can change the meaning of a tier (e.g., add library access to "Premium") without re-assigning every patient: every Premium patient inherits the change.

Money flow: today vs. tomorrow

Today (Phase 1): the clinic owns the patient billing relationship.

• The clinic charges the patient through whatever channel they already use — invoicing, point-of-sale, an existing accounting system.
• When the patient pays for Premium, the clinic (or their existing system) tells the platform: "this patient is now Premium." The platform updates the patient's tier; permissions follow.
• RestartiX never sees patient money. We are not a payment processor and not a marketplace at this stage.

Tomorrow (later phase): optional platform-mediated billing (Stripe Connect or equivalent).

• The patient pays through the platform's checkout. Money flows through RestartiX, we take a fee, we remit the rest to the clinic.
• Clinics opt in. Those who already have billing systems they like can stay on the today-model indefinitely.
• This unlocks a second revenue stream for RestartiX (transaction fees on patient subscriptions in addition to platform plan fees).

The schema is built to support both from day one — the difference is which payment integration is wired up. Choosing to go marketplace is a strategic decision, not a re-architecture.

---

How the two levels interact

The platform plan sets the possibilities the clinic has access to. The clinic, within those possibilities, designs its own patient tiers.

Concrete example:

A clinic on the Pro plan with the Telerehab Pack add-on can offer their patients:

• A Basic tier (free or low-cost): standard appointments, intake forms.
• A Premium tier (paid, e.g., 200 RON/month): standard appointments plus specialist-assigned treatment plans plus exercise library access.

If the same clinic drops the Telerehab Pack add-on, they lose the ability to assign treatment plans. Existing patients on Premium keep their tier — but new treatment plan assignments stop. Patient data is never deleted because of a billing change. The clinic decides whether to renew the add-on or restructure the Premium tier without telerehab.

If the clinic upgrades to White-Label with a custom contract, they can offer however many tiers they want — Bronze / Silver / Gold / Corporate / Insurance / Family — within whatever capacity their contract grants.

---

Five principles the model is built on

These are deliberate design choices, with strategic consequences worth understanding.

1. Plans do not grant permissions; roles do

A plan unlocks features (e.g., the platform allows you to use telerehab). It does not say who within the clinic can use telerehab — that's the clinic's role configuration.

The strategic consequence: changing pricing tiers does not break clinic-internal permission setups. Promoting a clinic from Pro to White-Label doesn't suddenly grant the receptionist admin powers. Demoting them from Pro to Free doesn't strip all their staff of access. Roles are stable; plans simply gate which capabilities exist.

This separation also supports white-label clinics that want non-standard role bundles ("hybrid specialist-receptionist," "clinic owner without clinical access"). They can define their own roles without us touching pricing logic.

2. Pricing changes do not break existing customers

When a customer subscribes to Pro at 490 RON / month with 1,000 patient capacity, those terms are frozen onto their subscription. Six months later, if we raise Pro to 590 RON / month with 2,000 capacity for new signups, the existing customer is grandfathered — they continue at 490 with 1,000.

We can offer them the upgrade at renewal, or as a sales-driven nudge, but we don't silently change a contract they've already agreed to.

The strategic consequence: pricing experimentation is safe. We can publish a new tier, raise prices, run a promotion, or restructure the catalog without legal risk to existing relationships, and without code changes for grandfathering — it's automatic.

3. Sales overrides are first-class

When a sales conversation lands a clinic on "Pro plan, but with 5,000 patient capacity and automations unlocked" because that's what closes the deal, we don't have to spin up a one-off custom plan. We grant a per-clinic override on top of the Pro snapshot, with a recorded reason and the granting party.

The strategic consequence: the sales motion has flexibility without engineering overhead. Negotiated contracts are recorded data, not custom code.

4. Multiple subscriptions stack

A clinic can hold a base plan plus N add-ons plus M usage packs simultaneously. Each is its own subscription, each is independently cancellable. Effective features and limits are the sum.

The strategic consequence: we can sell narrowly (the clinic only takes what they need), package broadly (White-Label bundles everything), and the math always works. New add-ons can be introduced without restructuring the base plans.

5. Medical features are gated separately from billing

Telerehab, integrated video, camera-based measurements — these are clinical features subject to medical device regulation (EU MDR Class IIa territory). They are gated by a separate capability layer that the platform turns on per-clinic when regulatory conditions are met.

The plan engine drives capabilities (a clinic on Pro + Telerehab Pack should have telerehab capability on), but clinical software does not read from the billing system directly — it reads from the capability layer.

The strategic consequence is two-fold:

• We can paywall clinical features without medical device certification entangling our pricing logic. Pricing changes don't trigger regulatory re-validation.
• We can disable a clinical feature for a specific clinic for regulatory reasons — without affecting their billing, and without rewriting their contract. The capability is the gate; billing is the lever that usually drives it.

This is what makes the platform medical-device-ready and commercially flexible at the same time.

---

The medical features question

A specific consequence of principle #5, called out separately because it's strategically important.

The platform's clinical features (telerehab assignments, exercise prescription, camera-based posture / range-of-motion measurement, integrated video consultations) fall inside the medical device regulatory boundary. EU MDR Class IIa is the realistic scope; this is documented in Medical Device Classification.

The commercial implication: we can sell these features through plans and add-ons, but they are also subject to a separate "is this clinic regulatory-cleared" gate that the platform controls.

Three patterns for how this plays out:

• Today, before MDR Class IIa is in place: clinical capabilities default to OFF. Plans can advertise them, but the platform doesn't actually unlock the clinical paths until the capability is enabled. This is a deliberate fail-safe state.
• Once certification lands: plans drive capabilities. A clinic on Pro + Telerehab Pack automatically gets the telerehab capability turned on at the platform level, no manual intervention.
• Per-clinic exception: a regulatory issue, a jurisdictional concern, or an incident can take a capability offline for a specific clinic without canceling their billing. The clinic stays on their plan; the capability is paused; we communicate the reason and ETA.

This is unusual for a SaaS — in most SaaS, "you paid, you have it." For medical software, "you paid AND the regulatory boundary is open" is the correct model. The platform is built for it from day one.

---

Roadmap

Phase	What's in place	What's next
Now (foundation)	Schema for plans, add-ons, usage packs, subscriptions, patient tiers, sales overrides, capability gating. Manual provisioning by RestartiX team.	—
Soon	Console UI for managing subscriptions and patient tiers. Self-service signup with a default plan. Capability projection (plan → capability automation).	Public pricing page; self-service plan upgrade flow.
Later	External billing integration (Stripe / Chargebee for invoicing platform plans). Sales-portal for negotiated contracts.	Marketplace mode (Stripe Connect for clinic→patient billing) — strategic decision, not a default path.
Long-term	Regulated capability projection from plans (telerehab, video) once MDR certification is in place. Usage-based metering for video minutes / storage.	Multi-currency billing for international expansion.

---

What this enables for the business

• Multiple revenue streams. Platform plans are the primary line; transaction fees on patient subscriptions become a second line if and when we go marketplace. No re-architecture needed for either.
• Sales flexibility. Negotiated contracts are recorded data, not custom code. Sales can close deals with non-standard terms in hours, not weeks.
• Pricing experimentation. Tiers, prices, packaging changes don't break existing customers (grandfathering is automatic) and don't require engineering effort beyond catalog edits.
• White-label readiness. Clinics define their own patient-tier shape. Their internal commercial model isn't constrained by ours.
• Compliance posture. Plan logic and clinical software are decoupled. Pricing changes don't trigger medical device re-validation. Clinical features can be regulated-disabled per-clinic without affecting their bill.

---

For developers

Technical architecture — schema, snapshot semantics, capability projection, middleware composition — is documented under Architecture › Plans & Subscriptions, Architecture › Org-Level Settings, and Architecture › Middleware Composition.