What are saas pricing models?

What “SaaS pricing models” means (and why medtech is different)

A SaaS pricing model is the rule-set for how you charge for access to your software over time—usually a recurring subscription (monthly or annual), sometimes combined with usage fees or services. In plain terms: it’s who pays, what they pay for, and how the bill scales as the customer uses your product more.

In medtech and digital health, pricing isn’t just “what the market will bear.” It’s constrained by:

• Buyer complexity: the user (clinician) is rarely the payer (hospital, health system, payer, employer).
• Procurement: hospitals often prefer predictable annual contracts, vendor onboarding, security reviews, and budget cycles.
• Reimbursement: if your product’s value depends on billing (e.g., RPM/CCM), your pricing must leave margin after staffing and payer rules.
• Regulatory pathway: if you’re Software as a Medical Device (SaMD), your FDA pathway (510(k), De Novo, PMA) can affect sales cycle length, evidence expectations, and willingness to pay.

So the “best” SaaS pricing model is the one that matches your value metric (the unit that correlates with customer value) and the way money moves in healthcare.

The core SaaS pricing models (with medtech examples)

1) Per user (seat-based) pricing

You charge per named user (or per concurrent user). This is common for clinician-facing tools.

• Works when: value scales with staff adoption; usage is relatively uniform across users.
• Medtech example: a radiology workflow tool priced per radiologist seat.
• Watch-outs: hospitals may resist paying for “inactive” seats; shared logins become a risk (and a compliance/security issue).

2) Per site / per facility pricing

You charge a flat fee per hospital, clinic, or facility (sometimes with tiers by size).

• Works when: deployment is site-based (integration, training, governance) and you want frictionless internal adoption.
• Medtech example: an ED clinical decision support platform priced per hospital site.
• Watch-outs: define “site” carefully (campus vs. department vs. affiliated clinics) to avoid scope creep.

3) Tiered plans (Good/Better/Best)

You package features into tiers (e.g., Basic/Pro/Enterprise). This is the most common B2B SaaS structure because it’s easy to understand and supports upsell.

• Works when: different customer segments need different capabilities (e.g., small clinics vs. IDNs).
• Medtech example: a remote patient monitoring platform with tiers based on integrations, analytics, and support levels.
• Watch-outs: don’t put “core clinical safety” features behind a paywall; keep tiers aligned to operational value (integrations, admin controls, reporting).

4) Usage-based pricing (pay-as-you-go)

You charge based on usage: API calls, messages sent, minutes analyzed, studies processed, patients monitored, etc.

• Works when: value scales tightly with volume and customers want to start small.
• Medtech example: an AI triage API priced per study analyzed (with volume discounts).
• Watch-outs: hospital budgeting prefers predictability; you may need committed minimums or a subscription + usage overage model.

5) Per patient / per member per month (PMPM)

You charge per patient enrolled (often monthly). This is common in care management and digital therapeutics-style programs.

• Works when: the product’s value is tied to active patient panels and outcomes.
• Medtech example: chronic care management software priced per active patient per month.
• Watch-outs: define “active” (enrolled vs. engaged vs. billed). If reimbursement is involved (e.g., CPT-driven programs), ensure your pricing leaves room for clinical labor and documentation overhead.

6) Outcome-based / value-based pricing

You charge based on achieved outcomes (reduced readmissions, improved adherence, shorter length of stay). This is attractive in theory and hard in practice.

• Works when: outcomes are measurable, attributable, and contractable.
• Medtech example: a post-discharge monitoring program where fees depend on readmission reduction vs. baseline.
• Watch-outs: attribution is messy (confounders, patient mix). Expect long sales cycles and heavy legal/finance involvement.

7) Freemium and free trials

You offer a limited free version (freemium) or time-limited access (trial) to reduce adoption friction.

• Works when: onboarding is self-serve and compliance/security requirements are manageable.
• Medtech reality: true freemium is rare in hospitals due to security reviews and PHI. Trials are more common, often as a paid pilot (see below).

8) Paid pilots (common in hospitals)

Not a “pricing model” in the classic SaaS sense, but a very common commercial step in medtech: a fixed-fee pilot for a defined scope and time period.

• Works when: you need clinical validation, workflow proof, and stakeholder buy-in before an enterprise contract.
• Best practice: pilot fee is creditable toward the annual contract if they convert, and success criteria are written up front.

How to choose the right model: start from your value metric

A value metric is the unit that best tracks the value the customer gets and the cost you incur. Good value metrics are:

• Easy to measure (no debates at invoicing time)
• Predictable for the buyer (budgetable)
• Aligned with outcomes (more value → higher bill feels fair)
• Hard to game (no incentive to under-report or share logins)

In medtech, common value metrics include:

• Per facility (procurement-friendly)
• Per clinician seat (workflow tools)
• Per study / per procedure (imaging/diagnostics throughput)
• Per active patient per month (monitoring/care management)

If you’re unsure, a practical approach is hybrid pricing: a base platform subscription (predictability) + a usage component (scales with value). Example structure: annual platform fee + per-study fee above a committed volume.

Medtech-specific pricing constraints you should design around

Hospital procurement and contracting

Hospitals often prefer annual contracts with clear scope, service levels, and renewal terms. Expect requirements like BAAs (for HIPAA), security questionnaires, and sometimes integration fees. Your pricing model should minimize “surprise” line items.

Reimbursement and CPT codes (when relevant)

If your product supports reimbursable workflows (e.g., remote monitoring or care management), pricing must account for the fact that reimbursement varies by payer, patient eligibility, and documentation. A useful rule: don’t price so aggressively that the provider can’t cover staffing time (nurses, MAs, care coordinators) plus your software.

Evidence, IRB, and regulatory pathway

If you need clinical evidence (sometimes under IRB oversight) to sell, your early pricing may need to fund pilots and studies. If you’re SaMD, the FDA pathway (510(k), De Novo, PMA) can influence how conservative buyers are and how long it takes to close—pushing you toward models that support longer sales cycles (annual contracts, implementation fees, paid pilots).

A simple pricing “starter stack” for early-stage medtech SaaS

If you’re pre-scale and selling into clinics/hospitals, a common, workable structure is:

1. Paid pilot: fixed scope (e.g., one department, one site), fixed duration, clear success metrics.
2. Annual subscription: per site or per seat, with a minimum contract value that covers onboarding and support.
3. Optional usage overages: only if usage varies widely and correlates with your costs (e.g., per study, per message).

This reduces procurement friction (predictable spend) while still letting you capture upside as adoption grows.

What to do next

1. Pick one value metric (per site, per seat, per patient, per study) and write a one-sentence rationale tied to customer value and your costs.
2. Draft 3 tiers (e.g., Core, Clinical, Enterprise) where tiers differ by integrations, admin controls, analytics, and support—not by essential safety features.
3. Design a paid pilot offer with success criteria (clinical workflow KPIs, adoption, time saved) and a conversion credit toward the annual contract.
4. Pressure-test with 10 buyer interviews (clinical champion + IT/security + finance/procurement) to see what is budgetable and contractable.
5. Model unit economics (implementation hours, support load, hosting costs) so your pricing doesn’t collapse at scale.

Helpful next steps on StartupLaby: /basics_form, /Competitor_study, /finances, /interviews.