What is saas pricing?

SaaS pricing is the way a software-as-a-service product charges customers for ongoing access to software that’s hosted and maintained by the vendor. Instead of a one-time license fee, SaaS is typically sold as a subscription (monthly or annual), often with tiers and add-ons.

In medtech and digital health, SaaS pricing has extra constraints: hospital procurement cycles, security reviews, integration costs (EHR/HL7/FHIR), and sometimes reimbursement (e.g., CPT codes) or regulatory scope (e.g., whether your software is considered Software as a Medical Device, SaMD). The “right” SaaS pricing is less about clever math and more about matching how your buyer budgets, measures value, and renews.

What SaaS pricing includes (and why it’s different from “software pricing”)

SaaS pricing usually bundles more than the app itself. Customers are paying for an ongoing service level, not a static product. A typical SaaS price implicitly covers:

• Hosting + uptime (cloud infrastructure, monitoring, backups)
• Security + compliance work (e.g., HIPAA controls, SOC 2 if you pursue it, vendor risk management questionnaires)
• Continuous updates (bug fixes, new features, regulatory updates)
• Support and onboarding (training, implementation, change management)
• Data handling (storage, retention, exports, audit logs)

This is why SaaS pricing is commonly expressed as a recurring fee and why buyers expect renewals, service-level agreements (SLAs), and a clear definition of what’s included vs. what’s an add-on.

Common SaaS pricing models (with medtech examples)

Most SaaS pricing is a combination of (1) a pricing metric (what you charge “per”) and (2) a packaging structure (tiers, modules, add-ons). Here are the models you’ll see most often in medtech:

1) Per user (seat-based)

Charge per clinician, per staff member, or per “named user.” This is common when value scales with staff usage (e.g., care coordination tools, imaging workflow software).

Medtech gotcha: hospitals may resist per-seat pricing if many users need occasional access (e.g., rotating residents). You may need “concurrent users” or role-based pricing (e.g., admin vs. viewer).

2) Per site / per facility (hospital-based)

Charge per hospital, clinic, or facility. This aligns with how many provider organizations budget (departmental or facility cost centers) and simplifies procurement.

Medtech gotcha: define “site” precisely (one campus vs. health system). Health systems will ask for enterprise pricing; be ready with a clear expansion path.

3) Usage-based (volume-based)

Charge based on usage: per study, per message, per patient monitored, per encounter, per device connected, etc. This can match value well when usage is measurable.

Medtech gotcha: buyers dislike unpredictable bills. Many successful medtech SaaS products use committed minimums (a contracted baseline) plus overage pricing.

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

Common in population health, remote patient monitoring (RPM), and chronic care management platforms. PMPM aligns with payer/provider contracts and care management programs.

Medtech gotcha: if your buyer is a provider relying on reimbursement (e.g., RPM-related CPT codes), they’ll evaluate whether your price fits inside their margin after staffing and device costs. The exact economics vary by setting and payer mix.

5) Module-based + add-ons

Core platform fee plus optional modules (analytics, additional clinical pathways, advanced integrations, extra audit logging). This is common when different departments need different capabilities.

Medtech gotcha: avoid “nickel-and-diming” for essentials like basic security features. Procurement teams may interpret that as risk.

How medtech SaaS pricing interacts with regulation, reimbursement, and procurement

In medtech, pricing isn’t just marketing—it can be constrained by how your product is classified and sold.

Regulatory scope (SaMD) and pricing expectations

If your software is SaMD (or part of a regulated workflow), customers may expect more documentation, validation, and change control. That can justify higher pricing, but it also increases your cost to serve.

FDA pathway (e.g., 510(k), De Novo, or PMA) doesn’t directly dictate price, but it affects:

• Sales cycle length (clinical evaluation, IT/security review, legal)
• Implementation burden (training, validation, QMS processes)
• Risk tolerance (buyers may pay more for proven safety/performance)

If you’re pre-clearance or still defining intended use, be careful about pricing promises tied to clinical outcomes you can’t yet substantiate.

Reimbursement and “who pays”

Some digital health products are purchased because they enable billable services (e.g., workflows that support RPM or chronic care management). In those cases, your pricing must fit into the buyer’s unit economics: staffing time, device costs, and claim success rates all matter. If there’s no clear reimbursement path, you’ll often need to price against cost savings (reduced readmissions, fewer no-shows) or revenue protection (capacity, throughput).

Hospital procurement realities

Hospitals often prefer:

• Annual contracts (easier budgeting than monthly)
• Clear implementation fees (one-time onboarding, integration)
• Predictable renewals (price increase caps, multi-year options)

Expect vendor risk management, HIPAA BAAs, and integration discussions early. If your product touches clinical workflows, you may also encounter IRB questions for pilots (varies by institution and whether it’s considered research vs. quality improvement).

How to choose a pricing metric (the “charge per what?” decision)

A practical way to choose your SaaS pricing metric is to align four things:

1. Value metric: what the customer gets more of when they get more value (e.g., patients monitored, studies processed).
2. Budget owner: who signs (department head, IT, innovation, population health, payer).
3. Measurability: can both sides count it the same way without disputes?
4. Scalability: does your revenue grow as usage grows without punishing adoption?

In medtech, a common failure mode is picking a metric that’s easy for you (like “per seat”) but misaligned with the buyer’s budget or workflow (where dozens of occasional users are required). Another failure mode is usage-based pricing that makes clinicians afraid to use the tool because “every click costs money.”

Packaging: tiers vs. enterprise

Packaging is how you group features into plans (e.g., Basic/Pro/Enterprise). A simple medtech-friendly structure is:

• Core: must-have clinical workflow + baseline security
• Plus: integrations, advanced reporting, multi-site management
• Enterprise: SSO, custom security requirements, dedicated support, complex integrations

Then add implementation as a separate line item when integration and training are real work. Buyers understand paying for services when it’s clearly scoped.

What to do next

1. Write down your buyer and budget owner (e.g., cardiology department vs. IT vs. population health) and confirm who actually signs.
2. Pick 2 candidate pricing metrics (e.g., per facility and per patient monitored) and test them in 10 customer calls for “does this match how you budget?”
3. Define packaging: list what’s included in Core vs. Enterprise, and separate one-time implementation if integrations are required.
4. Model unit economics: estimate cost to onboard/support one customer and ensure your annual contract value can cover it with margin.
5. Pressure-test procurement: ask what security reviews, BAAs, and integration steps are required before a paid contract.

If you want feedback on your pricing page and packaging, run it through /roast or compare competitors’ pricing patterns in /Competitor_study.