How to price saas software?

Start with the buyer, not the product (medtech SaaS is rarely “self-serve”)

In medtech, “How to price SaaS?” is really “Who pays, who uses it, and who approves it?” Your pricing has to survive three conversations: the clinician/user (workflow), the economic buyer (budget), and procurement/compliance (risk). If any one of those groups can’t justify the purchase, your price is effectively wrong—even if it’s “market rate.”

Map your buyer chain before you pick a number:

• User: clinician, nurse, tech, care manager, research coordinator
• Champion: service line lead, medical director, informatics lead
• Economic buyer: department admin, VP/Director, CFO, payer partner
• Gatekeepers: IT security, privacy, legal, compliance, sometimes IRB (if research)

Then decide whether you’re selling departmental SaaS (one service line), enterprise SaaS (hospital-wide), or payer/provider network (multi-site). Each implies different pricing metrics and contract structures.

Choose a value metric that matches clinical reality

A value metric is the unit you charge for (e.g., per user/month). In healthcare, the wrong metric creates friction (e.g., per-seat pricing punishes adoption in team-based care). The right metric aligns with how value is created and how budgets are allocated.

Common medtech SaaS value metrics (and when they work)

• Per clinician seat (per month/year): works for documentation, decision support, analytics tools used by a defined group. Risk: discourages broad rollout.
• Per facility / per site: works for hospital operations, imaging workflow, device fleet management. Easier for procurement; aligns with site budgets.
• Per bed (licensed beds) or per department: common for inpatient workflow tools. Useful when usage scales with capacity.
• Per study / per protocol (research SaaS): fits IRB-driven workflows and grant-funded budgets; aligns with research administration.
• Per patient managed / per member per month (PMPM): fits chronic care management, remote monitoring, population health. Requires strong outcomes story and careful definitions.
• Per procedure / per case: fits perioperative, cath lab, imaging, and specialty pathways. Works when you can tie value to throughput, complications, or supply utilization.

Rule of thumb: pick a metric that (1) the buyer can estimate quickly, (2) doesn’t penalize the behavior you want (adoption), and (3) maps to a budget line item they already recognize.

Build pricing from value: a defendable anchor, not a guess

Most first-time founders either copy competitors or pick a “reasonable” number. In regulated healthcare, you’ll be asked to justify price in committees. Use a simple value-based pricing anchor: quantify the economic impact you create, then charge a fraction of it.

A practical value model you can do in one spreadsheet

1. Pick 1–2 primary outcomes you improve (e.g., reduced no-shows, faster report turnaround, fewer adverse events, fewer readmissions, fewer manual hours). Avoid trying to price on 10 benefits.
2. Translate outcomes into dollars using the buyer’s language:
   • Cost savings: staff time saved, reduced overtime, reduced supplies, fewer repeat tests
   • Revenue lift: increased throughput, improved coding capture, fewer denials
   • Risk reduction: fewer safety events, better compliance (harder to price; use as justification, not the sole anchor)
3. Estimate conservatively (procurement will discount your claims). Use ranges and show assumptions.
4. Set price as a share of value (often a minority share). The exact share varies by category, switching costs, and proof strength.

Example (illustrative, not a benchmark): If your SaaS reduces manual chart review by 10 minutes per patient for a service line seeing 8,000 patients/year, that’s ~1,333 hours/year. Multiply by a fully loaded hourly cost (varies by role and institution). If the value is clearly larger than your annual fee, you have a defendable story for a committee.

Don’t ignore reimbursement and billing realities

If your product’s value proposition depends on reimbursement, you need to understand the pathway early:

• CPT codes: If your SaaS supports billable services (e.g., remote monitoring workflows), pricing must leave margin after clinical labor and vendor costs. Code availability and payer coverage vary.
• Hospital DRG / bundled payment environments: Hospitals may value cost avoidance and length-of-stay reduction more than “new revenue.”
• Grant-funded or research budgets: Pricing may need “per study” packaging and language compatible with IRB/protocol timelines.

Package into tiers that procurement can buy (and IT can approve)

Pricing is the number; packaging is what they get for that number. In healthcare, packaging must also address security, integration, and support expectations.

A simple tier structure that works for many medtech SaaS products

• Starter (department pilot): limited sites/users, standard support, minimal integrations, clear success metrics. Goal: fast approval.
• Professional (production): full department rollout, SSO, audit logs, role-based access, basic integrations (e.g., HL7/FHIR where relevant), stronger SLA.
• Enterprise: multi-site, advanced security reviews, dedicated CSM, custom integrations, data retention controls, uptime SLA, procurement-friendly terms.

Common add-ons (often priced separately): implementation, EHR integration, data migration, premium support, advanced analytics modules, additional environments (sandbox), and validation documentation if needed.

Why this matters: Hospitals often can’t buy “a little bit of enterprise.” If your base tier lacks what security/procurement requires (SSO, audit logs, BAAs, etc.), the deal stalls. Make the minimum “buyable” tier realistic for your target customer.

Be explicit about regulatory scope (it affects willingness to pay)

Some digital health SaaS is not a medical device; some is Software as a Medical Device (SaMD). If your product makes diagnostic/treatment recommendations, your customers may ask about FDA pathway (commonly 510(k), De Novo, or PMA depending on risk and predicate availability). Regulatory posture influences pricing because it changes perceived risk, implementation burden, and clinical trust.

If you’re pre-clearance (or not pursuing clearance), price and package accordingly: you may need narrower claims, more “workflow” positioning, and stronger pilot terms.

Use pilots and contracts strategically (without underpricing yourself)

In medtech SaaS, pilots are normal—but “free pilot” can signal low value and create procurement headaches. Instead, structure pilots so they create evidence and a clean conversion path.

Pilot pricing patterns that tend to work

• Paid pilot with a credit: customer pays a smaller amount; if they convert, you credit part of it toward year 1. This protects your time and signals seriousness.
• Time-boxed evaluation: 60–90 days with defined success metrics (e.g., adoption rate, time saved, turnaround time). Avoid open-ended trials.
• Implementation fee + subscription: even a modest implementation fee can filter out non-buyers and cover integration work.

Contract terms matter as much as price: annual prepay vs monthly, auto-renewal, termination clauses, data ownership, BAAs, and security obligations. Procurement will negotiate; bake that into your pricing model.

Discounting: do it for a reason, not because they asked

Use discounts to buy something valuable:

• Multi-year commitment
• Multi-site rollout
• Case study rights (if feasible)
• Reference calls
• Faster signature / reduced sales cycle

Avoid “healthcare discount” as a default. If you discount without getting anything, you train the market that your list price is fake.

What to do next

1. Write your buyer-chain map (user, champion, economic buyer, gatekeepers) and pick one primary buyer for your first 10 customers.
2. Pick one value metric (per site, per bed, per patient managed, etc.) and sanity-check it with 5 target customers in discovery calls.
3. Build a one-page value calculator with 3–5 assumptions and a conservative ROI range you can defend in a committee.
4. Define 3 tiers + 2 add-ons that match procurement reality (security, SSO, audit logs, integration) and your delivery costs.
5. Run a paid pilot template (60–90 days, success metrics, conversion terms) and iterate pricing after 3–5 pilots based on close rates and implementation burden.

If you want a structured way to pressure-test your pricing and packaging against competitors and procurement constraints, use /Competitor_study and then sanity-check unit economics in /finances.