How much is saas?

“How much is SaaS?” has two meanings: (1) what it costs you to build and run a SaaS product, and (2) what you should charge customers. In medtech/digital health, both are heavily shaped by compliance (HIPAA), security reviews, integrations (EHR, SSO), and long hospital sales cycles.

Below is a practical pricing map you can use even if you’ve never taken a business class. I’ll define jargon once as we go.

1) Typical SaaS price ranges (what customers pay)

SaaS is usually sold as a subscription (monthly or annual). In healthcare, annual contracts are common because procurement prefers predictable budgets and vendors prefer lower churn (customer cancellations).

Common medtech SaaS pricing bands

• Individual clinician / small practice: often priced per user per month (e.g., a clinician seat). Usually low to mid hundreds per month total, depending on value and workflow impact.
• Department / clinic: often priced per seat, per site, or per department. Typically moves into thousands per month when multiple roles are involved (clinicians + admin + analysts).
• Hospital / health system enterprise: commonly priced per facility, per bed, per covered life, or as a platform fee + usage. Enterprise deals can reach tens to hundreds of thousands per year (and sometimes more) when you include integrations, security requirements, and service levels.

Reality check: in medtech, the “sticker price” is only part of the commercial package. Enterprise buyers often expect (a) implementation support, (b) training, (c) a security posture they can approve, and (d) contract terms that pass legal/procurement.

2) What drives SaaS cost in medtech (why healthcare SaaS is rarely “cheap”)

Even if your app is simple, healthcare buyers will evaluate you like a risk-bearing vendor. That adds real cost and influences your minimum viable price.

Key cost drivers (and how they show up)

• HIPAA + BAA: If you touch protected health information (PHI), you’ll need a Business Associate Agreement (BAA) and operational controls (access logging, least privilege, incident response). This increases engineering and legal overhead.
• Security reviews: Hospitals may require security questionnaires, penetration testing, vulnerability management, and sometimes specific certifications. The time cost alone can be significant.
• Integrations (EHR, SSO, HL7/FHIR): Integration work is rarely “one and done.” Each health system can have different configurations and change-control processes.
• Implementation + support: In healthcare, “customer success” often includes workflow mapping, training, and go-live support. That’s labor cost you must price in.
• Regulatory classification: If your software is Software as a Medical Device (SaMD), you may face FDA pathways like 510(k), De Novo, or PMA depending on risk and predicate devices. Regulatory work can change your timeline and cost structure (and therefore pricing expectations).
• Clinical evidence and IRB: If you need clinical validation, you may need an Institutional Review Board (IRB) approval and a study plan. Evidence can be a sales requirement even if FDA clearance isn’t.

Bottom line: medtech SaaS pricing often needs to cover not just servers, but the “enterprise readiness” layer.

3) The 4 most common SaaS pricing models in medtech (and when to use each)

Pick a pricing model that matches (a) how value is created and (b) how procurement can approve it.

A) Per-seat (per user) pricing

Best when: value scales with the number of active staff (e.g., clinicians using a decision support tool).
Risk: hospitals may restrict seats to control cost, limiting adoption.

B) Per-site / per-facility pricing

Best when: you’re deployed as a standard workflow tool across a unit or hospital (e.g., a perioperative dashboard).
Benefit: simpler for procurement than counting seats.

C) Usage-based pricing (per study, per message, per patient)

Best when: your costs scale with volume (e.g., imaging AI reads, remote monitoring events).
Risk: budgeting becomes harder for buyers; you may need caps/tiers.

D) Outcomes/value-based pricing

Best when: you can credibly measure and attribute outcomes (reduced readmissions, fewer no-shows, faster throughput).
Reality: harder to contract and measure; often used as an add-on or pilot structure.

4) How to set your SaaS price (a defendable method for STEM founders)

Most first-time founders either underprice (“to get adoption”) or overprice (“because hospitals have money”). Use a simple framework that ties price to value and your go-to-market motion.

Step 1: Define the buyer and the budget owner

In hospitals, the user (clinician) is often not the economic buyer. Identify who signs: department chair, service line leader, IT, finance, or procurement. Your price must fit their budget category.

Step 2: Quantify value in one of three buckets

• Revenue lift: more billable procedures, improved coding, fewer denials. If reimbursement is involved, understand whether there are relevant CPT codes (billing codes) or whether your product is “non-billable” but operationally valuable.
• Cost reduction: fewer complications, reduced length of stay, less staff time. Even “minutes saved per patient” can be meaningful if multiplied by volume.
• Risk reduction: improved compliance, fewer adverse events. Harder to price, but powerful in sales.

Then price as a fraction of value. Many B2B SaaS products aim to capture a minority of the economic value created, leaving the buyer with a clear ROI (return on investment).

Step 3: Choose a pricing metric that doesn’t punish adoption

If you want broad clinical adoption, avoid pricing that makes champions feel they’re “spending more every time they succeed.” Per-facility or tiered pricing often works better than strict per-seat in hospital settings.

Step 4: Add enterprise “must-haves” as paid tiers

Common add-ons that justify higher tiers:

• SSO (single sign-on) and role-based access control
• Audit logs and admin reporting
• EHR integration (FHIR/HL7), data export, custom interfaces
• Higher support SLAs (service-level agreements), dedicated onboarding

This prevents your base price from being inflated for small customers while still monetizing enterprise complexity.

5) What it costs you to run SaaS (so you don’t price below your floor)

Your internal cost structure matters because medtech sales cycles can be long. You need enough gross margin (revenue minus direct costs) to survive procurement timelines.

Typical cost categories

• Cloud + data: hosting, storage, backups, monitoring. Costs vary widely by architecture and volume.
• Security/compliance operations: policies, training, vendor management, incident response readiness.
• Support + implementation labor: onboarding, training, troubleshooting, integration maintenance.
• Regulatory and quality (if SaMD): quality management system processes, documentation, post-market monitoring. The FDA pathway (510(k), De Novo, PMA) changes scope and effort.

Practical rule: if each new hospital requires significant integration and onboarding labor, you’re not selling “pure SaaS” yet—you’re selling a product + services package. Price accordingly (often with an implementation fee or a higher first-year price).

What to do next

1. Pick your first pricing model (per-seat, per-site, usage, or hybrid) and write a one-sentence rationale tied to value and procurement simplicity.
2. Run 10 buyer interviews focused on budget ownership: “Who signs?”, “What line item?”, “What’s an easy approval threshold vs. committee review?”
3. Create a 3-tier price sheet (Starter / Pro / Enterprise) where Enterprise includes SSO, audit logs, and integrations—things hospitals expect to pay for.
4. Map your regulatory and evidence needs: decide whether you are SaMD and which FDA pathway is relevant (510(k), De Novo, PMA), and whether you need IRB-backed validation to sell.
5. Model your unit economics (gross margin and onboarding labor per customer) so you don’t accidentally price below your support burden.

If you want feedback on your specific product and buyer, you can run a structured critique using our tools.