How to price software as a service?

Start with the buyer reality in medtech (it’s rarely “the user”)

Pricing software as a service (SaaS) in medtech starts with one uncomfortable truth: the clinician who loves your product often isn’t the person who signs the contract. In hospitals and health systems, you typically have users (clinicians, nurses, techs), an economic buyer (department head, service line leader, CFO), and gatekeepers (IT, security, compliance, legal, sometimes a value analysis committee).

That means your price has to map to how money moves inside healthcare:

• Budget line: Is this coming from IT, a clinical department, quality/safety, research, or revenue cycle?
• Procurement motion: Annual contracts, vendor onboarding, security review, BAAs (for HIPAA), and sometimes RFPs.
• Proof requirement: A pilot (paid or unpaid), references, and a clear ROI story.

Before you pick a number, write down: (1) who uses it daily, (2) who owns the budget, (3) what KPI they’re judged on (throughput, complications, length of stay, denials, staffing), and (4) what happens if they do nothing.

Choose a value metric that matches clinical value (not your engineering)

A value metric is the unit you charge for that scales with customer value. In SaaS outside healthcare, that might be “per seat.” In medtech, “per seat” often breaks because value is tied to patients, procedures, sites, or volume—not logins.

Common medtech SaaS value metrics (and when they work)

• Per facility / per site: Good when deployment and compliance overhead is site-based (security review, integration, training). Works well for hospital-wide platforms.
• Per department / service line: Good when value is localized (e.g., radiology, cath lab, OR). Helps land-and-expand.
• Per clinician (seat): Works when usage is truly individual and measurable (e.g., decision support used by specific providers). Beware: hospitals resist paying for “named users” if staff turnover is high.
• Per patient / per episode: Strong when you can tie value to outcomes or operational savings per case (e.g., remote monitoring, post-op pathways). Requires clean volume definitions.
• Per study / per trial / per protocol: Common for research and IRB-driven workflows. Aligns with grant-funded budgets.
• Per integration / per interface: Sometimes used for EHR connectivity (HL7/FHIR). Usually better as a one-time implementation fee than recurring.

Rule of thumb: pick the metric that (a) the buyer can forecast, (b) you can measure without drama, and (c) scales with value delivered. If your value is “reduced OR delays,” charging per seat is a mismatch; charging per OR suite or per procedure volume is usually closer.

Build packaging: 3 tiers that reflect risk, compliance, and outcomes

Packaging is what’s included at each price point. In medtech, packaging should reflect not only features, but also implementation effort, regulatory/compliance posture, and clinical support.

A practical 3-tier structure:

1. Starter (land): Limited scope (one site or one department), core workflow, basic reporting, email support, minimal integrations.
2. Clinical (expand): Adds advanced analytics, role-based access controls, audit logs, SSO, and one or more EHR integrations. Includes onboarding and training.
3. Enterprise (standardize): Multi-site, centralized admin, security documentation package, uptime/SLA, dedicated support, custom integrations, and governance features.

Medtech buyers often pay for reduced risk. Features like audit trails, access controls, and security attestations are not “nice-to-haves” in hospitals—they are procurement accelerators. Put them in higher tiers if they create real incremental cost for you, but don’t hide essentials that block adoption.

Implementation fees are normal—use them strategically

Many founders underprice implementation because it feels “un-SaaS.” In healthcare, implementation is where you absorb integration, workflow mapping, training, and change management. A one-time implementation fee can (1) cover your real costs, (2) signal seriousness to procurement, and (3) reduce churn by ensuring proper rollout.

Anchor price to ROI and budget impact (with simple math)

Hospitals buy when you can credibly show either (a) new revenue, (b) cost reduction, (c) risk reduction, or (d) strategic necessity. Your price should be a fraction of the value created, but still fit a budget line.

Use a “value-based ceiling” and a “cost-based floor”

• Cost-based floor: Your minimum viable price to cover hosting, support, compliance overhead, and sales effort. If you can’t estimate this yet, build a simple model (support hours per site per month, cloud costs, vendor management time).
• Value-based ceiling: The maximum a rational buyer would pay given expected benefit. This is where you use ROI logic.

Example ROI framing (use your real numbers): If your software reduces no-show rates, shortens length of stay, decreases readmissions, improves coding/denials, or increases throughput, translate that into dollars the buyer recognizes. Keep it conservative and transparent.

In the US, reimbursement can matter. If your product directly enables billable services, you’ll need to understand whether there are relevant CPT codes (billing codes used for reimbursement) and who captures that revenue (hospital vs physician group). If reimbursement is unclear or “varies,” don’t promise it—position value around operational efficiency or quality metrics instead.

Don’t ignore the FDA/regulatory posture—it affects willingness to pay

If your SaaS is a clinical decision support tool or otherwise could be considered Software as a Medical Device (SaMD), your regulatory pathway (often 510(k), De Novo, or PMA depending on risk and predicate availability) can change buyer expectations. Some customers will pay more for a product with a clear regulatory strategy and documentation; others will avoid you until it’s settled. Price and packaging should reflect what you can responsibly claim today.

Design your pricing to survive procurement: pilots, terms, and expansion

Medtech SaaS deals often start with a pilot. Your pricing should make pilots easy to approve while protecting you from “endless evaluation.”

Pilot pricing patterns that work

• Paid pilot with credit: A 60–90 day pilot fee that converts into annual subscription credit if they sign. This reduces friction and avoids free consulting.
• Fixed-scope pilot: One site, one workflow, defined success metrics, and a clear end date. Include what data access you need.
• Research/IRB pathway: If the hospital wants to evaluate under research, you may need IRB approval. That can slow timelines; price accordingly and keep scope tight.

Contract terms that reduce churn and increase close rate

• Annual prepay is common in hospitals. Monthly can be harder for procurement.
• Multi-year discounts can help if you’re confident in retention, but avoid deep discounts that lock you into underpricing.
• Clear data/security posture: HIPAA, BAA readiness, and security questionnaires are part of the “price” in time and effort. Bake that cost into enterprise tiers.

Finally, plan your land-and-expand motion: start with one department/site at a price that’s easy to approve, then expand to additional sites, service lines, or volumes using your value metric (per site, per procedure, etc.). Your pricing should make expansion feel like a logical next step, not a renegotiation battle.

What to do next

1. Write your pricing hypothesis: buyer, value metric, 3 tiers, and one-time implementation fee (even if “varies”).
2. Run 10 pricing interviews with economic buyers (not just users): ask about budget ownership, approval thresholds, and what they currently pay for alternatives.
3. Build a one-page ROI model with conservative assumptions and the KPIs your buyer cares about (throughput, denials, staffing, quality).
4. Define a paid pilot template: 60–90 days, fixed scope, success metrics, and conversion credit into annual contract.
5. Pressure-test procurement readiness: BAA, security questionnaire, SSO needs, and any IRB/research constraints before quoting enterprise pricing.