What is a saas fee?

What is a SaaS fee (in plain terms)?

A SaaS fee is the recurring price a customer pays to use Software as a Service (SaaS)—software delivered over the internet (cloud) rather than installed on a local server. Instead of buying a one-time license, customers typically pay monthly or annually to access the product, updates, hosting, and support.

In medtech and digital health, the “SaaS fee” is often the commercial wrapper around things like:

• Access (logins for clinicians, admins, analysts)
• Infrastructure (hosting, backups, uptime monitoring)
• Security/compliance work (audit logs, encryption, SSO, role-based access)
• Ongoing improvements (new features, bug fixes, regulatory maintenance)
• Support (training, help desk, implementation)

Think of it as “renting” the software plus the operational services that keep it reliable and compliant.

Common SaaS fee structures (and what they mean in medtech)

SaaS fees can be priced in several ways. The right model depends on who gets value (clinicians, the hospital, the patient), how usage scales, and how procurement prefers to buy.

1) Per user (seat-based) pricing

You charge per named user (or per concurrent user). This is common when value is tied to clinician or staff access (e.g., care coordination dashboards, analytics portals).

• Pros: easy to understand; aligns with access control.
• Cons: hospitals dislike “nickel-and-diming” seats; can slow adoption if every new user increases cost.

2) Per site / facility pricing

You charge per hospital, clinic, or department. This fits enterprise procurement and encourages broader internal rollout.

• Pros: simpler contracting; supports “land and expand.”
• Cons: you must define what counts as a “site” (main campus vs satellite clinics).

3) Per device pricing (common in connected medtech)

If your software is tied to hardware (e.g., a connected diagnostic device, remote monitoring kit, or smart implant ecosystem), pricing per active device can align well with value and cost-to-serve.

• Pros: scales with deployments; intuitive for biomedical engineering and supply chain stakeholders.
• Cons: you need clean device inventory/activation tracking.

4) Usage-based pricing (per patient, per study, per scan, per message)

You charge based on measurable usage—often a “per patient per month” (PPPM) or “per episode” model. This can map to clinical volume and sometimes to reimbursement logic.

• Pros: aligns price with value delivered; easier to start small.
• Cons: forecasting and budgeting can be harder for hospitals; you must define usage precisely (what counts as a patient, an encounter, a message, etc.).

5) Tiered subscription (Basic/Pro/Enterprise)

You bundle features into tiers. This is common when different customers need different compliance/security features (e.g., SSO, advanced audit logs, data retention controls).

• Pros: clear upsell path; matches maturity levels.
• Cons: you must be careful not to put “safety” features behind paywalls in a way that creates risk.

What’s usually included in a SaaS fee (and what’s not)

Founders often underprice because they think they’re selling “just software.” In healthcare, customers expect clarity on what the subscription covers versus what is a separate professional service.

Typically included

• Software access (web app, mobile app, admin console)
• Hosting and maintenance (cloud compute, storage, backups)
• Security baseline (encryption, access controls, audit trails—details vary)
• Standard support (response time and hours vary by plan)
• Updates (feature releases, patches)

Often charged separately (one-time or recurring add-ons)

• Implementation / onboarding (workflow mapping, configuration)
• EHR integration (HL7/FHIR interfaces, testing, change management)
• Data migration (historical data import/cleanup)
• Custom reporting or bespoke analytics
• Premium support (24/7, dedicated CSM, faster SLAs)
• Validation documentation or customer-specific security assessments

In hospital procurement language, these “separate” items are often categorized as professional services (time-and-materials or fixed-fee) versus the recurring subscription.

Medtech-specific considerations: FDA, reimbursement, and hospital procurement

In medtech, your SaaS fee isn’t just a pricing decision—it can affect regulatory strategy, sales cycle length, and who signs the contract.

1) FDA pathway and “software as a medical device” (SaMD)

If your software performs medical functions (e.g., diagnosis, treatment recommendations), it may be considered Software as a Medical Device (SaMD). Your regulatory pathway could be 510(k), De Novo, or PMA depending on risk and predicate availability. The SaaS fee itself doesn’t determine the pathway, but your claims, intended use, and risk classification do.

Practical pricing implication: regulated products often require more ongoing quality management (change control, documentation, post-market monitoring). Make sure your SaaS fee covers that operational load.

2) Reimbursement and budget ownership

Hospitals buy software from different budgets: IT, clinical department, innovation, or sometimes a service line. If your product’s ROI depends on reimbursement (e.g., remote monitoring workflows), you’ll need to understand how CPT codes and payer policies influence adoption. Your SaaS fee should be easy for a department to justify against either cost savings, revenue capture, or quality metrics.

If reimbursement is central, customers may ask for pricing that scales with patient volume (e.g., PPPM) so costs track with reimbursable activity. Whether that works for you depends on your gross margin and usage variability.

3) Hospital procurement and contracting realities

Enterprise healthcare buyers often prefer:

• Annual terms (easier budgeting than monthly)
• Multi-year agreements with price holds or modest escalators
• Clear data/security terms (risk assessments, BAAs when applicable)
• Defined implementation scope (who does what, by when)

Also expect security reviews and, for research deployments, potential IRB approval depending on whether you’re collecting data for research versus operations. These steps add time and cost—your SaaS fee and services fees should reflect the true sales and delivery effort.

How to set a SaaS fee: a practical founder method

Here’s a simple way to avoid guessing.

1. Pick a pricing unit tied to value: user, site, device, or patient. Ask: “What grows when value grows?”
2. Estimate cost-to-serve per unit: hosting, support load, integration maintenance, compliance overhead. (Exact numbers vary; the point is to model it.)
3. Define your buyer and budget: IT vs department head vs supply chain. Your unit should match how they think and buy.
4. Set a minimum annual contract value: hospitals often require meaningful contract sizes to justify procurement effort. Even if you allow pilots, define what converts to “real.”
5. Separate subscription vs services: keep the recurring SaaS fee clean; charge implementation/integration explicitly so you don’t destroy margins.

If you’re early, you can start with a simple structure (e.g., per site per year + one-time implementation) and evolve once you have real usage data.

What to do next

1. Write your pricing one-liner: “We charge $X per unit per month/year, plus $Y for implementation.” Keep it procurement-friendly.
2. List what’s included vs add-on (support hours, integrations, training, SLAs) and turn it into a one-page pricing sheet.
3. Pressure-test with 5 target buyers (clinical champion + IT/security + procurement) and ask what would block purchase.
4. Model two scenarios: small pilot and enterprise rollout; confirm your SaaS fee covers support, compliance, and integration maintenance.
5. Run a quick competitive check to see how similar vendors package subscription vs services.