Pricing SaaS based on how much it cost to develop?

Why “cost to develop” is a bad pricing anchor for medtech SaaS

Pricing SaaS based on how much it cost to develop (a cost-plus approach) feels rational: you add up engineering, cloud, compliance, and then add a margin. The problem is that in B2B healthcare, buyers don’t pay for your effort—they pay for risk reduction, workflow impact, and economic value (or at least budget fit).

Cost-plus fails in medtech SaaS for three structural reasons:

• Your costs are not correlated with customer value. A feature that took 2 weeks might eliminate hours of nursing time; a feature that took 6 months might be “nice to have.”
• It ignores buyer constraints. Hospital procurement, security review, legal, and clinical leadership create a buying process where price must fit a category (software, service, device add-on) and a budget owner.
• It punishes you for being efficient. If you build faster, cost-plus would push your price down—even if the product is equally valuable.

Use your development cost for what it’s good at: financial planning (runway, burn, break-even), not as the primary pricing model.

What medtech SaaS buyers actually pay for

In healthcare, “value” is often indirect. Your buyer might be a clinical champion, but the budget holder could be IT, a service line administrator, revenue cycle, or a quality/safety leader. Your pricing needs to map to the value story that survives procurement.

Common value buckets (with concrete pricing implications)

• Labor/time savings: If your software saves clinician or staff time, price can be justified as a fraction of the loaded cost of that time. Procurement will still ask: “Who captures the savings?” If the savings accrue to nursing but IT pays, you need internal alignment.
• Revenue lift: Examples include fewer denials, improved documentation, better charge capture, or enabling billable services. This can support per-encounter or per-provider pricing—if you can show attribution.
• Risk reduction: Security, compliance, adverse event reduction, or reduced readmissions. These often support enterprise pricing because the value is system-wide and tied to governance.
• Clinical outcomes: Hardest to price early unless you have strong evidence. If you’re making claims that could trigger medical device regulation, your FDA pathway (510(k), De Novo, or PMA) and evidence plan will affect both timeline and willingness to pay.

In short: your price should be anchored to the economic buyer’s value narrative, not your internal cost narrative.

Use development cost correctly: floor pricing, not market pricing

Development cost still matters, but as a floor and a survival constraint:

• Unit economics: Know your gross margin (SaaS typically targets high gross margins, but in healthcare you may have higher support, onboarding, and compliance costs). Include cloud hosting, third-party APIs, customer success, security tooling, and ongoing maintenance.
• Implementation burden: Medtech SaaS often has non-trivial onboarding: SSO, EHR integration, HL7/FHIR mapping, security questionnaires, BAAs, and training. If implementation is heavy, you may need a one-time implementation fee or a higher annual contract value (ACV).
• Regulatory and evidence costs: If your product is Software as a Medical Device (SaMD), budget for quality management (e.g., ISO 13485-style processes), clinical evaluation, and possibly IRB-approved studies. These costs should influence your business model and sales cycle expectations, not directly set your price.

A practical rule: compute a minimum viable price that covers (1) variable costs to serve + (2) a realistic allocation of support/implementation + (3) enough contribution margin to fund ongoing development. Then validate whether the market will pay above that floor.

Better pricing methods for medtech SaaS (and when to use each)

Instead of cost-plus, use one of these approaches (often combined):

1) Value-based pricing (best when you can quantify ROI)

Estimate the annual value created and price at a reasonable share of it. You don’t need perfect precision; you need a defensible model.

• Example: If your tool reduces documentation time by 3 minutes per patient for a clinic seeing 20,000 visits/year, that’s 60,000 minutes (~1,000 hours). If the loaded cost of staff time is “varies,” you can still show a range and price below the conservative case.
• Good for: Workflow automation, revenue cycle, scheduling, triage, imaging ops, device fleet management.

2) Market-based pricing (best when there are clear comparables)

Study competitors and adjacent tools. In hospital software, pricing is often opaque, but you can triangulate via RFPs, customer interviews, and “budget category” expectations.

• Good for: Security/compliance tools, analytics dashboards, care coordination platforms where buyers have reference points.

3) Risk-based pricing (best when you reduce liability or compliance burden)

If you reduce audit pain, improve traceability, or lower the chance of a serious event, buyers may accept higher enterprise pricing—especially if your product helps them pass internal governance gates.

• Good for: Clinical quality systems, device surveillance, medication safety workflows, cybersecurity posture improvements.

4) Cost-to-serve + tiering (best early, when value is uncertain)

Early-stage founders often can’t quantify outcomes yet. In that case, price with simple tiers that scale with usage while ensuring you don’t lose money on high-touch accounts.

• Common metrics: per site, per provider, per bed, per device, per study, per API call (use carefully in healthcare), or per module.
• Include: a one-time implementation fee if integration/training is real work.

Medtech-specific pricing traps (FDA, CPT, procurement)

Don’t confuse reimbursement with pricing

If your SaaS enables a billable service, you’ll hear about CPT codes. A CPT code (or reimbursement pathway) can strengthen willingness to pay, but it doesn’t automatically dictate your price. Reimbursement rates, payer mix, and coverage policies vary, and hospitals may not pass incremental revenue to the budget holder paying for your software.

Be careful with SaMD claims and FDA pathway implications

If you market diagnostic or treatment claims, you may fall under FDA regulation. The pathway (510(k), De Novo, PMA) affects timeline, evidence needs, and buyer confidence. Pricing too early around “clinical outcomes” without evidence can backfire in procurement and compliance reviews. Align pricing promises with what you can substantiate.

Procurement reality: price must match the buying unit

Hospitals buy in ways that don’t map neatly to your engineering cost. They buy:

• Per facility / per site when governance and deployment are centralized.
• Per department / service line when budgets are siloed (ED, radiology, cardiology).
• Enterprise agreements when IT/security wants standardization.

Design your packaging so a department can start small (pilot) but procurement can later expand to enterprise without renegotiating from scratch.

A simple pricing workflow you can run in 2 weeks

1. Define your economic buyer and budget source. IT? Quality? Service line admin? Revenue cycle? Write one sentence: “The person who signs is ___ because ___.”
2. Build a one-page ROI model. Use ranges and conservative assumptions. Focus on 1–2 measurable outcomes (time saved, denials reduced, throughput increased).
3. Pick a pricing metric that matches value capture. If value scales with sites, price per site. If it scales with providers, price per provider. Avoid metrics that punish adoption (e.g., per message) unless costs truly scale that way.
4. Create 3 tiers. Example: Pilot (limited scope), Standard (department), Enterprise (multi-site + security/SLAs). Keep the differences tied to governance needs (SSO, audit logs, integrations), not arbitrary feature gating.
5. Test with 10 buyer conversations. Ask “How would this be budgeted?” and “What would make this a no-brainer vs. too expensive?” You’re looking for procurement fit, not compliments.

What to do next

• Calculate your floor price (cost-to-serve + support + implementation) and write it down so you don’t negotiate below survival.
• Run a competitor and adjacent-tool scan to triangulate realistic ACV ranges using /Competitor_study.
• Pressure-test your pricing metric with 5–10 target buyers and capture how it would be procured (department vs enterprise).
• Build a simple ROI sheet you can share in sales calls; then refine it after each pilot.
• Model runway and break-even under 2–3 pricing scenarios using /finances.