Founder Guide

How to set saas pricing?

SL
StartupLaby Editorial · 2026-04-27 · 3 min read

Medtech SaaS pricing is not just “what competitors charge.” It’s a design problem: you’re choosing (1) who pays (hospital, clinic, payer, pharma, patient), (2) what they pay for (your value metric), and (3) how the contract survives procurement, compliance, and reimbursement realities.

Below is a practical framework you can use even if you’ve never done pricing before—written for clinicians, biomedical engineers, and researchers building digital health and software-enabled medical device businesses.

1) Start with the buyer map: user ≠ buyer ≠ economic owner

In healthcare, the person who loves your product is often not the person who can sign the contract. Before you pick a price, write down three roles:

  • User: who touches the product daily (nurse, physician, care manager, lab tech).
  • Buyer: who runs the purchasing process (procurement, IT, supply chain, digital health committee).
  • Economic owner: who benefits financially (department chair, CFO, value-based care leader, payer partner).

Pricing fails when you optimize for the user’s willingness to pay (often low) instead of the economic owner’s budget line. A clinician may say “I’d pay $50/month,” but the hospital may have a budget for “quality improvement software” or “remote patient monitoring operations” that is orders of magnitude larger—if you can justify ROI and fit procurement.

Actionable output: a one-page “buyer map” with (a) who signs, (b) which budget it comes from, and (c) what success metric that budget owner cares about (LOS, readmissions, throughput, documentation time, denial rates, etc.).

2) Choose a value metric that matches clinical workflow and procurement

A value metric is the unit you charge on (per provider, per bed, per site, per patient monitored, per study, per API call, etc.). In medtech SaaS, the best value metrics share three properties:

  • Aligned to value: as the customer gets more value, they naturally pay more.
  • Easy to measure and audit: procurement hates ambiguous usage.
  • Hard to game: avoids “shadow usage” or under-reporting.

Common medtech SaaS value metrics (and when they work)

  • Per provider (per NPI) / per clinician seat: good for documentation, decision support, imaging workflow, and tools embedded in clinician work. Risk: departments argue about who “counts.”
  • Per facility / per site: good for hospital-wide platforms (integration-heavy, IT-managed). Procurement-friendly; can be expensive but simpler.
  • Per bed (licensed beds): common in inpatient operational tools. Works when value scales with census capacity.
  • Per patient monitored per month: common in remote monitoring and chronic care. Works when patient volume drives your costs and value.
  • Per study / per procedure: good for diagnostics workflow, imaging AI triage, or perioperative tools. Works when tied to throughput.

Rule of thumb: if your product requires significant integration, security review, and change management, avoid tiny per-user pricing that makes the contract look small but the effort huge. Hospitals will balk at a $5k/year contract that still requires months of IT/security work.

3) Anchor pricing to ROI, then sanity-check with willingness-to-pay

Value-based pricing starts with a simple ROI model. You don’t need perfect numbers; you need a defensible story that matches how the buyer thinks.

Build a one-page calculator with:

  • Baseline: current time/cost/outcome (e.g., minutes per note, denial rate, no-show rate, readmission rate).
  • Delta: expected improvement from your product (from pilot data, literature, or conservative assumptions).
  • Economic conversion: what that delta is worth (labor cost, capacity, avoided penalties, improved collections).
  • Who captures value: department vs hospital vs payer (this determines who will pay).

Then pick a price that captures a fraction of the value (often framed as “we deliver X, we charge Y”). The exact fraction varies by category, competition, and switching costs—so don’t hardcode a universal percentage. Instead, use pricing interviews to test willingness-to-pay (WTP): what budget exists, what alternatives cost, and what approval thresholds trigger extra scrutiny.

Procurement reality: many organizations have approval tiers (department head, finance, committee). Your pricing should anticipate the friction of crossing a threshold. Ask directly: “At what annual spend does this require CFO approval?”

4) Design tiers and packaging that fit healthcare buying

Packaging is what’s included at each level; pricing is what you charge. In medtech, packaging often matters more than the number itself because it determines implementation effort, compliance scope, and who must be involved.

A practical 3-tier structure for medtech SaaS

  1. Starter (department pilot-ready): limited sites, limited integrations, standard support, basic reporting. Goal: fast time-to-value and a clean pilot.
  2. Professional (scale within a service line): SSO, audit logs, role-based access, advanced analytics, more workflows, priority support.
  3. Enterprise (hospital system): multi-site, dedicated success, custom security requirements, integration support, SLAs, data retention/BAA terms, and governance features.

In healthcare, “Enterprise” often really means “we can survive security + compliance + integration.” Make sure your top tier includes what IT and compliance will ask for: SSO/SAML, logging, access controls, data export, uptime commitments, and a Business Associate Agreement (BAA) if you handle PHI.

Implementation and services: don’t hide the real cost

If your product requires EHR integration, workflow redesign, or training, consider separating:

  • Platform fee (recurring): the software license.
  • Implementation fee (one-time): integration, onboarding, validation, training.

This reduces sticker shock when the buyer realizes the true effort. It also prevents you from underpricing a complex deployment and then drowning in support.

5) Medtech-specific constraints: FDA pathway, reimbursement, IRB, and procurement

Your pricing strategy should reflect your regulatory and commercialization path:

If your software is a medical device (SaMD)

If you’re pursuing FDA clearance/authorization (e.g., 510(k), De Novo, or PMA depending on risk and predicate availability), buyers may delay broad rollout until regulatory status is clear. That affects packaging:

  • Pre-clearance: price pilots as evaluation/innovation projects with clear scope and endpoints. Avoid promising clinical claims you can’t support.
  • Post-clearance: shift to outcome-linked ROI and scale pricing (site/bed/service line).

If reimbursement is part of your value story

Some digital health products rely on reimbursement (e.g., RPM, CCM) or improved collections. If you mention CPT codes, be precise: coding applicability depends on setting, payer, documentation, and who provides the service. Your pricing can be:

  • Revenue-share / per patient enrolled: aligns with collections but can trigger compliance scrutiny and longer contracting.
  • Flat license + optional billing support: simpler procurement; you sell “enablement” rather than taking a cut.

IRB and evidence generation

If your early deployments require IRB approval (common in academic centers), timelines are longer and scope is narrower. Price these as paid pilots with explicit deliverables (implementation, training, reporting) rather than “discounted annual contracts.” You’re being paid for structured evaluation and evidence creation.

Hospital procurement and security review

Expect security questionnaires, vendor onboarding, and legal review. Two pricing implications:

  • Minimum contract size: set a floor so you’re not doing enterprise-level work for a tiny deal.
  • Multi-year options: offer 2–3 year terms with modest discounts to justify the onboarding effort on their side and stabilize your revenue.

What to do next

  1. Write your buyer map (user, buyer, economic owner) and identify the budget line you’re targeting.
  2. Pick one primary value metric (per site, per bed, per patient-month, etc.) and define it unambiguously in one sentence.
  3. Build a one-page ROI calculator with conservative assumptions and a clear “who benefits” statement.
  4. Run 10 pricing interviews with target buyers and ask about approval thresholds, procurement steps, and what they pay for alternatives.
  5. Draft a 3-tier package including security/compliance features and a separate implementation fee if integrations are required.

If you want a structured way to pressure-test your positioning and pricing logic, use StartupLaby’s tools below.

Ready to actually build it?

Your idea, validated in 60 seconds.

Drop your startup idea. Get a brutal, honest AI verdict — score, red flags, and a shareable summary.

Roast my idea