How to calculate saas pricing?

Start with the pricing “unit”: what exactly are you charging for?

To calculate SaaS pricing, you need a value metric—the unit that scales with customer value and usage. In medtech, the wrong unit creates procurement friction (hard to approve) or margin problems (costs scale faster than revenue).

Common medtech SaaS value metrics (pick one primary):

• Per clinician seat (e.g., radiologist, nurse, care manager). Simple for budgeting; can be misaligned if value is per patient or per study.
• Per facility / per site (hospital, ASC, clinic). Procurement-friendly; works when usage varies but value is organization-wide.
• Per study / per exam / per report (imaging AI, diagnostics workflow). Strong alignment to value; must handle volume variability and integration costs.
• Per patient per month (PPPM) (remote monitoring, chronic care). Aligns to outcomes programs; requires clarity on enrollment and churn.
• Per device / per bed (connected devices, inpatient monitoring). Matches asset footprint; watch for “shelfware” objections.

Rule of thumb: choose the metric that best matches how the hospital measures the problem (volume, staffing, length of stay, readmissions) and how you incur costs (support, compute, integrations).

Calculate your price floor: unit economics (COGS + support + compliance)

Your price floor is the minimum you can charge and still build a viable business. For SaaS, founders often underestimate costs that are unusually real in medtech: integrations, security reviews, clinical validation, and customer success time.

Use a simple per-account model:

• COGS (cost of goods sold): hosting, inference/compute, third-party APIs, monitoring, data storage, SMS, etc.
• Implementation cost: HL7/FHIR integration, SSO, EHR app listing steps, testing, training. (Often front-loaded; decide what you include vs charge separately.)
• Ongoing support: tickets, workflow tuning, model monitoring, quarterly business reviews.
• Security/compliance overhead: SOC 2 work, HIPAA processes, vendor risk questionnaires. (Some of this is fixed, but it still consumes real labor.)

Then compute gross margin:

Gross Margin = (Revenue − COGS) / Revenue

Many SaaS businesses target high gross margins, but in early medtech SaaS, margins can be lower due to integration and support. That’s okay temporarily—just don’t price as if those costs are zero.

Two practical pricing-floor checks:

• Payback period: how many months of gross profit to recover acquisition + implementation costs. If implementation is heavy, you may need annual contracts or implementation fees.
• Worst-case usage: if you price per study, model the highest-volume site. Make sure compute/support doesn’t explode.

Calculate your price ceiling: value-based pricing tied to clinical and financial outcomes

Your price ceiling is what the customer can justify paying based on measurable value. In medtech, value is often a mix of:

• Revenue lift (more billable volume, fewer denials, better coding, faster throughput)
• Cost reduction (labor time saved, fewer adverse events, fewer readmissions, reduced length of stay)
• Risk reduction (compliance, safety, missed findings)

Build a simple ROI model with conservative assumptions. You’re not trying to “prove” the best case—you’re trying to create a procurement-safe story.

A basic ROI worksheet (use ranges)

• Baseline volume: e.g., studies/month, patients enrolled/month, discharges/month.
• Delta: time saved per case, reduced no-shows, reduced readmissions, improved turnaround time.
• Dollar conversion: loaded hourly wage for staff time; contribution margin per additional case; penalty avoidance (varies by program).
• Confidence level: what you can support with pilot data vs literature vs hypothesis.

Then set pricing as a fraction of value created. In enterprise healthcare, a common approach is to price at 10–30% of expected annual value when value is clear and attributable; if value is less direct, you may need lower pricing or a different metric (e.g., per seat) to reduce scrutiny.

Important: if your product is tied to reimbursement (e.g., remote patient monitoring, chronic care management), your ceiling is constrained by what the provider can realistically capture. That depends on payer mix, documentation burden, and whether the workflow is actually adopted.

Account for medtech constraints: FDA pathway, IRB, reimbursement, and procurement

Medtech SaaS pricing isn’t just math—it’s constrained by how hospitals buy and how regulated your claims are.

1) Regulatory status affects sales cycle and pricing structure

If your software is a medical device (SaMD) or part of a regulated workflow, your FDA pathway (e.g., 510(k), De Novo, or PMA) can change buyer expectations and timelines. Even if you’re not yet cleared, be careful about claims and how you position “clinical decision support.”

Pricing implication: longer sales cycles often favor annual contracts and multi-year commitments so you can recover acquisition and implementation costs.

2) IRB and evidence requirements

Some hospitals will require IRB approval for pilots that involve patient data or prospective evaluation. That can slow time-to-value. Pricing implication: consider a paid pilot with a clear scope (e.g., 90 days, defined endpoints) rather than a free trial that drags on.

3) Reimbursement and CPT codes

If your product enables billable services (e.g., workflows that support CPT-coded programs), your pricing can be anchored to the provider’s net revenue after staffing and operational costs. Don’t assume the CPT code automatically means profit—collection varies, and operational burden can be the limiting factor.

4) Hospital procurement realities

Procurement cares about budget categories, contract risk, and comparability. Make pricing easy to approve:

• Keep tiers simple (2–3 tiers max).
• Separate one-time implementation from recurring subscription when integration is real work.
• Offer an “out”: termination for convenience after year 1, or performance milestones in pilots.

Choose a pricing model and compute the actual numbers (a practical method)

Here’s a concrete way to calculate SaaS pricing without guessing:

1. Pick one primary value metric (e.g., per facility, per study, PPPM). Define it precisely (what counts, what doesn’t).
2. Model your cost per unit (COGS + support) and your cost per account (implementation, security review time). Decide what’s included.
3. Estimate customer value per unit using a conservative ROI model (ranges). Document assumptions.
4. Set a target share of value (start lower if value is uncertain; increase as evidence strengthens).
5. Pressure-test against procurement: can the buyer explain it in one sentence? Does it fit a budget line? Is it comparable to alternatives?
6. Create tiers that map to buyer maturity, not features for their own sake.

Example tiering that works in hospitals

• Essential: core workflow + basic reporting (lowest friction).
• Clinical: advanced analytics, additional modules, more integrations.
• Enterprise: SSO, audit logs, custom integrations, dedicated support/SLA, multi-site rollouts.

Then decide whether to add:

• Implementation fee (common when EHR integration is required)
• Usage overages (only if usage can spike unpredictably)
• Multi-year discount (use sparingly; tie to rollout scope)

Finally, validate with 10–20 pricing conversations. Don’t ask “What would you pay?” Ask: “Which budget would this come from?”, “What would you need to see to justify $X/year?”, and “Who signs?”

What to do next

1. Write your one-page pricing model: value metric, tiers, what’s included, implementation fee, contract term.
2. Build a conservative ROI calculator (spreadsheet) with ranges and clearly labeled assumptions.
3. Run 10 procurement-informed interviews with clinical, IT/security, and finance stakeholders to test budget fit and approval path.
4. Decide your pilot policy: paid vs unpaid, duration, endpoints, and what converts to the annual contract.
5. Pressure-test unit economics for your highest-volume customer scenario and adjust metric/tier boundaries accordingly.

If you want feedback on your pricing page or tier structure, submit it for a teardown at /roast.