What are saas products?

Definition: what a SaaS product is (in plain terms)

SaaS stands for Software as a Service. A SaaS product is software that customers access over the internet (usually in a browser or app) and pay for on a recurring basis (monthly/annual). Instead of “buying software once and installing it,” the customer subscribes and you (the vendor) host, maintain, and continuously update it.

Three characteristics usually define SaaS:

• Hosted by the vendor: you run the servers/cloud infrastructure; the customer doesn’t manage deployments.
• Recurring revenue: subscription pricing (per user, per site, per device, per patient, or usage-based).
• Continuous delivery: frequent updates, bug fixes, and new features without “reinstalling.”

If you’re coming from clinical or engineering backgrounds, a useful mental model is: SaaS is like a “living” product—part software, part operations. Your uptime, security, support, and release process are part of what customers buy.

How SaaS differs from “regular software” and from medical devices

Traditional software is often sold as a perpetual license (one-time purchase) and installed on-premise. SaaS is typically cloud-based and subscription.

In medtech, the bigger confusion is between SaaS and Software as a Medical Device (SaMD). They can overlap, but they’re not the same:

• SaaS describes delivery and business model (hosted + subscription).
• SaMD describes regulatory intent: software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device.

So you can have:

• Non-regulated SaaS (e.g., scheduling, billing analytics) that still handles PHI and needs HIPAA-grade security.
• Regulated SaaS/SaMD (e.g., clinical decision support that recommends therapy adjustments), where FDA pathway considerations (510(k), De Novo, PMA) may apply depending on claims and risk.

Practical implication: in medtech, “SaaS” answers how you ship and charge; FDA answers what you’re allowed to claim and how you validate.

Common SaaS product types in medtech (with concrete examples)

Medtech SaaS often sells to hospitals/health systems, clinics, payers, or life sciences teams. Here are common categories and what makes them “SaaS.”

1) Clinical workflow SaaS

Examples: referral management, OR scheduling optimization, care pathway checklists, discharge coordination, prior authorization workflow tools. These are typically sold per facility or per seat and integrate with EHRs.

Key buying constraint: hospital procurement and IT/security review (often longer than founders expect).

2) Remote patient monitoring (RPM) platforms

Examples: dashboards that ingest vitals from connected devices, alerting rules, patient messaging, clinician triage queues. Often priced per patient per month or per monitored patient.

Key business constraint: reimbursement. If your value proposition depends on RPM billing, you’ll need to understand how CPT codes (billing codes used for reimbursement) and documentation requirements affect adoption. The exact codes and payment rates vary by payer and setting, so don’t build a model that assumes a single universal rate.

3) Imaging and diagnostics support SaaS

Examples: AI triage, structured reporting, quality control, radiology workflow tools. These can be regulated if they influence diagnosis or treatment decisions.

Key regulatory constraint: your claims and risk classification drive whether you’re in 510(k), De Novo, or PMA territory. If you’re making diagnostic claims, expect more rigorous validation and quality processes.

4) Device-connected SaaS (the “platform” around hardware)

Examples: device fleet management, calibration logs, usage analytics, clinician training modules, post-market surveillance dashboards. This is common for medical device companies that want recurring revenue beyond the one-time hardware sale.

Key operational constraint: uptime and data integrity. If the SaaS is essential to safe use, your quality system and change control matter a lot.

5) Research and clinical trials SaaS

Examples: eConsent, ePRO (patient-reported outcomes), site monitoring dashboards, data capture and cleaning tools. These may require IRB approval (Institutional Review Board) depending on how they’re used and what data is collected.

Key constraint: data governance and auditability (who changed what, when, and why).

How SaaS products make money: pricing and metrics founders should know

SaaS monetization is usually subscription-based, but the unit matters. Common pricing models in medtech:

• Per user (seat): common for clinician-facing tools; watch out for “shared logins” and role-based access needs.
• Per site / per facility: aligns with hospital procurement; easier budgeting for departments.
• Per patient per month: common in RPM and chronic care workflows; requires clear patient attribution.
• Usage-based: per study, per message, per analysis, per device connected—can match value but complicates forecasting.

Three SaaS metrics you’ll hear constantly:

• MRR/ARR: Monthly/Annual Recurring Revenue—your subscription revenue run-rate.
• Churn: the percentage of customers (or revenue) that cancels over time. In hospitals, churn can be low once embedded, but sales cycles are long.
• LTV and CAC: Lifetime Value (gross profit you expect from a customer) and Customer Acquisition Cost (sales + marketing cost to win them). In medtech, CAC can be high due to procurement, security reviews, pilots, and integrations.

Medtech-specific reality: you may need to budget for integration work (EHR interfaces, SSO, HL7/FHIR), which can look like “services.” Many successful SaaS companies still do this early—just be explicit about what’s product vs. implementation.

Medtech SaaS: compliance, procurement, and regulatory traps

In consumer SaaS, you can often launch with a credit card checkout and iterate fast. In medtech, you still iterate—but within constraints.

Security and privacy (even if you’re not FDA-regulated)

If you handle PHI (Protected Health Information), you’ll likely need HIPAA-aligned controls and a BAA (Business Associate Agreement) with customers. Expect security questionnaires, penetration testing requests, and vendor risk assessments.

Hospital procurement and “who actually buys”

Clinicians may love your product, but purchasing often involves IT, compliance, legal, and finance. Your sales process must map stakeholders:

• Champion: the clinician or operator who feels the pain.
• Economic buyer: who owns the budget (department head, VP, CFO).
• IT/security: approves integration and risk.
• Compliance/legal: contracts, BAAs, data use.

This is why medtech SaaS founders should treat “sales” as a technical project: requirements, dependencies, timelines, and acceptance criteria.

FDA pathways (when SaaS becomes a medical device)

If your SaaS makes medical claims—diagnosis, treatment recommendations, or drives clinical decisions—you may be in FDA territory. The pathway (510(k), De Novo, PMA) depends on intended use and risk. Don’t guess: align claims, labeling, and validation plans early. Many teams start with a narrower, non-regulated workflow claim and expand later once they have evidence and quality systems.

What to do next

1. Write your “intended user + intended use” in one paragraph and mark which features touch diagnosis/treatment decisions (this clarifies FDA risk and product scope).
2. Pick one pricing unit (per site, per user, per patient) and draft a simple 12-month revenue model with assumptions that can vary.
3. Map the hospital buying process for your target customer: champion, economic buyer, IT/security, compliance/legal, and expected procurement steps.
4. List your required integrations (EHR, SSO, device APIs) and decide what’s “must-have for pilot” vs. “post-pilot.”

Useful StartupLaby resources: /basics_form, /launchpad, /Competitor_study, /finances.