How to price saas?

Start with the buyer, not the product

“How to price SaaS?” in medtech is really: who pays, for what outcome, under what constraints. Unlike generic B2B software, you often have multiple stakeholders:

• Economic buyer: CFO, VP of Revenue Cycle, VP of Operations, service line admin.
• Clinical champion: physician lead, nursing director, quality/safety lead.
• IT/security: integration, SSO, SOC 2, HIPAA, vendor risk.
• Procurement: contracting, vendor onboarding, pricing comparables.

Before you pick a number, write a one-page “pricing brief” answering:

• Who signs? (hospital, clinic group, payer, pharma, device company)
• What budget line? (IT, quality, operations, research, revenue cycle)
• What is the measurable value? (time saved, avoided adverse events, reduced readmissions, increased throughput, improved coding capture)
• What is the adoption unit? (a department, a site, a provider group, a device fleet)

This prevents the common STEM-founder mistake: pricing based on engineering effort (“we spent 12 months building it”) instead of buyer value and purchasing mechanics.

Choose a value metric that matches clinical reality

A value metric is the unit you charge on (per user, per site, per patient, per study, per device). In medtech, the best value metrics share three traits: (1) the buyer can forecast them, (2) they scale with value delivered, and (3) they don’t punish adoption.

Common medtech SaaS value metrics (and when to use them)

• Per facility / per site: good for hospital-wide tools (quality dashboards, interoperability layers). Easier for procurement; avoids “seat counting.”
• Per department / service line: good when value is localized (ED triage, cath lab workflow, radiology ops).
• Per clinician seat: works for clinician-facing productivity tools, but can slow adoption if every new user triggers cost scrutiny.
• Per patient monitored / per active patient per month: common in remote patient monitoring (RPM) and chronic care workflows; aligns with volume but needs clear definitions (active, enrolled, monitored).
• Per device / per device-month: strong for connected device fleets and biomedical engineering workflows.
• Per study / per protocol: for research/IRB-driven products (clinical trials ops, data capture). Often pairs with IRB approval timelines and study budgets.

Rule of thumb: if your product’s value increases when more clinicians use it, avoid a pure per-seat model unless you have a “site license” cap or an enterprise tier.

Build pricing from willingness-to-pay using a simple ROI model

Medtech buyers rarely buy “software.” They buy a business case. Your job is to quantify it in their language. Create a lightweight ROI calculator with 3–5 inputs and show conservative ranges (because outcomes vary).

Step 1: Define the economic outcome

Pick one primary value driver for pricing conversations:

• Cost reduction: fewer manual hours, fewer denials, fewer complications.
• Revenue increase: improved coding/documentation, increased capacity/throughput, better patient retention.
• Risk reduction: compliance, safety, audit readiness (harder to price; use as supporting value).

Step 2: Translate to dollars with conservative assumptions

Examples of inputs that buyers understand:

• Minutes saved per encounter × encounters per month × loaded labor cost (varies).
• Reduction in denial rate × claims volume × average claim value (varies).
• Additional patients per clinic day × contribution margin per visit (varies).

Then set pricing as a fraction of expected value. A common approach is value-based pricing: charge ~10–30% of the annual value you create, adjusted for switching costs and competitive alternatives. You don’t need to quote that percentage explicitly; you use it to sanity-check your number.

Step 3: Anchor with a “land and expand” structure

Hospitals are cautious. A practical structure is:

• Pilot (time-boxed, scoped): proves workflow + outcomes.
• Initial deployment: one site or one service line.
• Enterprise expansion: multi-site, integrations, governance.

Make sure your pilot price is high enough to qualify serious buyers but low enough to reduce perceived risk. If you offer a free pilot, you’ll often attract teams without budget authority.

Design tiers that map to procurement and compliance

In medtech, tiers are less about “Basic/Pro” features and more about scope, risk, and support. A clean tiering model also reduces custom contracting.

What to include in tiers

• Scope: sites, departments, devices, patient volume.
• Integrations: EHR (HL7/FHIR), SSO, data warehouse, device APIs.
• Security/compliance: HIPAA BAA, audit logs, retention policies, vendor risk documentation.
• Support: onboarding hours, training, SLA, dedicated CSM.
• Analytics/outcomes reporting: especially if you need to justify renewal.

Implementation fees (don’t hide them)

Many medtech SaaS deals include a one-time implementation fee (integration + workflow configuration + training). Buyers accept this when it’s clearly tied to work and timelines. If you’re early, implementation revenue can also fund customer success while you mature the product.

Account for FDA, reimbursement, and evidence requirements

Pricing depends on whether you’re “just software” or Software as a Medical Device (SaMD). If your product influences diagnosis/treatment, you may face FDA pathways like 510(k), De Novo, or PMA depending on risk and predicates. Regulatory status affects:

• Sales cycle length: evidence generation and review can slow adoption.
• Liability and risk perception: buyers may demand stronger validation.
• Value proof: you may need clinical studies, sometimes under IRB approval, to support claims.

Reimbursement is another pricing constraint. If your SaaS enables billable services (e.g., RPM workflows), the ceiling is influenced by what the provider can realistically collect under relevant CPT codes (coding and payment vary by payer and setting). In that case:

• Price so the provider still has margin after staffing and operational costs.
• Consider pricing tied to “patients successfully billed” only if you can measure it reliably and you’re comfortable with revenue-share complexity.

If there is no direct reimbursement, you’ll win on operational ROI (time, throughput, quality metrics) and you should price against those outcomes instead.

How to test and iterate pricing without burning deals

Pricing is a hypothesis. Validate it with structured conversations and controlled experiments.

1. Run 10–15 pricing interviews with real economic buyers. Ask: “What budget would this come from?” and “What would make this a no-brainer vs. too expensive?”
2. Quote ranges, then narrow. Early on, present a bracket (e.g., pilot vs. annual) to learn willingness-to-pay without locking yourself in.
3. Use a pricing page internally before public. Many medtech startups keep pricing off the website initially due to customization and procurement variability.
4. Track discount reasons. If every deal needs 30% off, your list price is wrong or your value story is weak.
5. Plan renewals from day one. Hospitals renew when you can show outcomes. Build reporting that maps to the buyer’s KPI (LOS, throughput, denial rate, time-to-documentation).

Also watch for procurement dynamics: some systems prefer multi-year contracts; others require annual renewals. Your pricing should be compatible with both (e.g., annual price with optional multi-year discount).

What to do next

• Pick one value metric (per site, per patient-month, per device) and write a one-paragraph justification tied to buyer value and adoption.
• Build a 5-input ROI calculator and test it with 5 clinicians + 5 economic buyers; adjust assumptions to be conservative.
• Create a 3-tier offer (Pilot, Department, Enterprise) including integrations, support, and an explicit implementation fee.
• Map your regulatory and evidence needs: confirm whether you’re SaMD and what level of validation/IRB work buyers will expect before scaling.
• Pressure-test pricing with a competitor study and a deal debrief template after every call.