How to determine saas pricing?

Start with the buyer, the budget, and the buying process

Medtech SaaS pricing is constrained less by what your product can do and more by who signs, which budget it comes from, and how hospitals buy. Before you touch a price sheet, answer three questions:

• Economic buyer: Who can approve spend? Commonly a department chair, service line leader, IT/security, or a value analysis committee (VAC). In smaller clinics it may be the practice owner/administrator.
• Budget line: Is this paid from IT, departmental operating budget, quality/safety, research, or a grant? (Grant-funded pilots often distort “real” willingness-to-pay.)
• Procurement path: Will this go through hospital procurement with vendor onboarding, security review, and contract redlines? If yes, expect longer cycles and higher friction—your pricing must justify that effort.

Business jargon, translated: economic buyer is the person with authority to spend; procurement is the formal purchasing process; a VAC evaluates clinical and financial value before a hospital will buy.

In medtech SaaS, pricing that ignores procurement reality often fails even if the product is clinically excellent.

Pick a value metric that matches how value is created (and measured)

Your value metric is the unit you charge for (per provider, per site, per bed, per study, per patient, per device, per message, etc.). The best value metrics in healthcare have three properties:

• Aligned: As customer value increases, your price scales.
• Measurable: The customer can verify usage/value without arguing.
• Procurement-friendly: It fits how hospitals budget and contract.

Common medtech SaaS value metrics (and when they work)

• Per facility / per site (annual): Often easiest for hospital procurement; good for workflow tools, dashboards, and enterprise integrations.
• Per clinician seat: Works when usage is clearly tied to specific users (e.g., interpretation, triage, care coordination). Watch for “shared logins” pressure.
• Per bed: Sometimes used in inpatient solutions; can map to scale but may be politically sensitive.
• Per study / per exam: Strong for imaging/diagnostics workflow where value scales with volume; can resemble a “usage-based” model.
• Per patient monitored / per member per month: Common in remote monitoring; be careful about churn, enrollment friction, and who pays (provider vs payer).
• Per device connected: Natural for device+software ecosystems; aligns with installed base growth.

Avoid value metrics that create internal conflict. Example: charging per alert can incentivize fewer alerts (good) but makes customers fear “runaway bills” (bad). If you do usage-based pricing, cap it or tier it.

Anchor pricing to ROI, but express it in procurement language

Clinicians buy on outcomes; hospitals approve on economics and risk. Build a simple ROI model (return on investment) that uses inputs your buyer recognizes. Keep it conservative and auditable.

Typical ROI buckets for medtech SaaS

• Labor/time savings: Minutes saved per case × fully loaded hourly cost × volume. (Fully loaded includes benefits/overhead; if you don’t know it, use the customer’s number.)
• Throughput/revenue: More cases per day, fewer cancellations, faster turnaround. Tie to existing CPT reimbursement only if the customer already bills for it.
• Avoided adverse events: Reduced complications, readmissions, infections. Harder to prove; best used as upside, not the sole justification.
• Compliance/risk reduction: Audit readiness, documentation completeness, reduced medico-legal exposure. Often compelling but difficult to quantify—use as qualitative support.

Important healthcare nuance: if your product’s value depends on reimbursement, you must understand CPT codes (billing codes used in the US) and who captures that revenue (hospital vs physician group). If there’s no clear reimbursement pathway, pricing must stand on operational ROI.

Also consider regulatory posture. If your software is Software as a Medical Device (SaMD), FDA pathway (e.g., 510(k), De Novo, or PMA) affects timelines and perceived risk. You generally shouldn’t price “as if” you’re cleared if you’re not; instead price pilots around evaluation and workflow value, then re-price post-clearance based on expanded claims and reduced buyer risk.

Design packages (Good/Better/Best) that map to hospital maturity

Packaging is how you bundle features and services into tiers. In healthcare, packaging should reflect integration complexity, compliance needs, and rollout support—not just feature checklists.

A practical 3-tier structure for medtech SaaS

• Essential: Core workflow, basic reporting, standard support. Minimal integrations.
• Professional: Role-based access, advanced analytics, SSO (single sign-on), audit logs, priority support.
• Enterprise: EHR integration (e.g., HL7/FHIR), custom security requirements, dedicated success, SLA (service-level agreement), multi-site management.

Business jargon, translated: SSO lets staff log in with hospital credentials; SLA is a contract promise about uptime/response times.

In medtech, integration is often the product. If you underprice integration-heavy deals, you’ll win contracts that lose money. Consider separating:

• Annual subscription (recurring revenue)
• Implementation fee (one-time: onboarding, configuration, training)
• Integration fee (one-time or annual, depending on maintenance)

Hospitals are used to this structure; it also protects your margins when each deployment is unique.

Validate willingness-to-pay with pilots, but don’t let pilots set your price

Early founders often price based on what a pilot site will pay. In healthcare, pilots are frequently discounted because the customer is taking risk and doing extra work. That’s fine—just separate pilot pricing from production pricing.

A pilot structure that supports future pricing

1. Define success metrics upfront: e.g., turnaround time reduction, adoption rate, fewer manual steps, fewer errors. If research is involved, consider whether IRB approval is required (Institutional Review Board) and build that timeline into the pilot.
2. Time-box it: 60–120 days is common; longer pilots become “free forever.”
3. Charge something: Even a modest fee filters non-serious buyers and tests procurement ability.
4. Include a conversion clause: If success criteria are met, the contract converts to annual pricing with pre-agreed tiers.

During validation, run a simple pricing interview script:

• “What budget would this come from?”
• “What alternatives do you pay for today (software, staffing, outsourcing)?”
• “At what annual price would this be an easy yes / a hard yes / a no?” (This is a willingness-to-pay range, not a single number.)

Then sanity-check against your unit economics: implementation hours, support load, cloud costs, and compliance overhead (security reviews, audits). If your gross margin can’t be healthy at your target price, you don’t have a pricing problem—you have a delivery-cost problem or a packaging problem.

What to do next

• Write a one-page pricing hypothesis: buyer, budget, value metric, 3 tiers, and what’s included/excluded.
• Run 10 pricing interviews with your economic buyer persona and capture “easy yes / hard yes / no” annual ranges.
• Build a conservative ROI calculator using the customer’s own inputs (time saved, volume, staffing costs) and use it in sales calls.
• Separate subscription vs implementation/integration so you don’t underprice deployment complexity.
• Test pilot-to-production conversion terms (success metrics + time-box + pre-set tier pricing) in your next 2 pilots.