Saas pricing features vs usage?

Features vs usage: what you’re really choosing in medtech SaaS

“Features vs usage” isn’t just a pricing debate—it’s a decision about who you sell to, how value is measured, and how a hospital can approve and pay you.

Feature-based pricing means customers pay for access to a bundle (e.g., “Pro includes HL7/FHIR integration, audit logs, and SSO”). It’s usually sold as a subscription per site, per department, or per clinician seat.

Usage-based pricing means customers pay as they consume (e.g., per study analyzed, per patient monitored per day, per message processed, per API call). It can track value more directly, but it can also trigger procurement and budgeting friction in hospitals.

In medtech, your pricing must survive: (1) clinical workflow reality, (2) hospital procurement, (3) reimbursement constraints (e.g., CPT codes), and (4) regulatory/compliance requirements (HIPAA, security controls, sometimes FDA pathways like 510(k), De Novo, or PMA if your software is a regulated device).

When feature-based pricing wins (common in hospitals)

Feature-based pricing tends to work best when your buyer needs predictability and a clean approval path.

Use feature-based pricing if:

• Budget owners want fixed costs. Many departments prefer annual subscriptions they can forecast. Variable bills can be a red flag for procurement.
• Value is “capability” more than “volume.” Example: security, compliance, integrations, and admin controls are valuable even at low usage.
• You sell to enterprise IT / security. They often evaluate you on controls: SSO/SAML, audit logs, role-based access control, data retention, BAA, SOC 2 (if you have it), etc. These map naturally to tiers.
• Usage is hard to measure fairly. In clinical settings, “a use” can be ambiguous (one patient, one encounter, one day, one alert, one clinician review?). Ambiguity creates billing disputes.

Medtech examples that fit feature tiers

• Clinical documentation/quality reporting SaaS: tiers by modules (e.g., measure sets, dashboards, export formats).
• Hospital command center / operations analytics: tiers by integrations (ADT feed, bed management, OR scheduling) and admin features.
• AI triage workflow tool (even if regulated): tiers by deployment options (on-prem vs cloud), governance, and monitoring.

Procurement reality: Feature tiers help you build a simple quote: “Site license + modules.” That’s easier to route through contracting than “we’ll bill you based on how many studies you do.”

When usage-based pricing wins (and how to make it hospital-friendly)

Usage-based pricing shines when your value scales tightly with volume and you can define a unit that feels fair.

Use usage-based pricing if:

• Your costs scale with volume. Example: compute-heavy AI inference, SMS outreach, or per-study processing.
• Your ROI is per event. Example: reducing readmissions per discharged patient, or improving throughput per imaging study.
• You start in outpatient / private practice / ASC settings. These buyers may accept variable billing more readily than large hospital systems.

Define a “billable unit” that matches clinical language

A good unit is (1) easy to count, (2) hard to game, and (3) aligned with perceived value. Common medtech SaaS units:

• Per study (imaging AI, radiology workflow)
• Per patient monitored per day (remote patient monitoring, inpatient monitoring overlays)
• Per encounter (ED decision support, documentation automation)
• Per message (HL7 interface engines, notification systems) — be careful: IT may see this as “taxing integration”

Hospital-friendly usage pricing trick: sell usage as a prepaid commitment (e.g., “includes up to X studies/year; overage at $Y”). This preserves predictability while keeping your upside.

The hybrid model: usually the best answer in medtech

Most successful medtech SaaS ends up hybrid because hospitals want predictable contracts, while founders need pricing that scales with value and cost.

A practical hybrid structure

• Base platform fee (annual): covers security, admin, integrations, onboarding, and support.
• Usage allowance: includes a reasonable volume so customers don’t fear surprise bills.
• Overage or growth tier: kicks in only when the customer is clearly getting more value.

This mirrors how many hospital contracts work: a fixed subscription plus defined add-ons. It also reduces the “we can’t budget for this” objection.

How to tier features without creating a compliance trap

In healthcare, some “features” are not optional luxuries—they’re table stakes for safe deployment. Be careful not to put essential controls behind the highest tier if it blocks adoption or raises risk concerns.

• Usually keep in every tier: audit logs (at least basic), access controls, encryption, BAA readiness, downtime procedures.
• Good tier differentiators: advanced analytics, additional integrations, multi-site management, custom workflows, premium support SLAs.

Decision framework: choose based on buyer, workflow, and reimbursement

Use this quick framework to decide:

1. Who signs? Department chair/clinical ops often prefers predictable site pricing; innovation teams may accept pilots with usage caps; IT/security cares about platform features.
2. What is the “value meter”? If value is per study/patient/day, usage makes sense. If value is “we can now do X safely,” feature tiers fit.
3. Can the customer pass through cost? If your product ties to reimbursable workflows (e.g., RPM programs with CPT codes), usage may map to revenue. If reimbursement is unclear or “varies,” fixed pricing reduces risk.
4. What’s the procurement path? Many hospitals prefer annual agreements. If you do usage, offer a committed minimum and a not-to-exceed cap.
5. Is the software regulated? If you’re pursuing 510(k), De Novo, or PMA (or you’re under a QMS), customers may expect validation, change control, and predictable releases—feature tiers plus contracted volumes can reduce friction.

Clinical research note: If you sell into studies, you may need IRB approval and a protocol-defined budget. In that case, per-study or per-subject pricing can work well, but you’ll want clear definitions (e.g., “subject enrolled” vs “subject monitored”).

Common pitfalls (and how to avoid them)

• Pitfall: pricing per clinician seat when usage is patient-volume driven. If one nurse monitors 200 patients, seat pricing under-monetizes. Consider per patient-day with a base fee.
• Pitfall: pricing per API call/message in hospital integrations. It can feel like you’re charging them for their own data plumbing. Prefer pricing per integrated system (EHR, PACS) or per site, with fair-use limits.
• Pitfall: too many tiers. Hospitals don’t want a menu of 12 options. Aim for 3 tiers max (e.g., Core, Clinical, Enterprise) plus a usage add-on.
• Pitfall: surprise overages. If you do usage, provide dashboards, alerts at 70/90/100% of allowance, and a contract cap.

What to do next

1. Write your “unit economics” sheet: list your main cost drivers (compute, support, integrations) and decide which should be covered by base fee vs usage.
2. Pick one billable unit that matches clinical language (per study, per patient-day, per encounter) and define it in one sentence to avoid disputes.
3. Draft a 3-tier packaging table with a base platform fee + included usage + overage, keeping compliance/security essentials available in all tiers.
4. Test pricing in 5 buyer calls: ask “Which part would procurement reject?” and “What would you need to budget this annually?” then revise.