A MedTech business model analysis is the exercise of choosing a revenue model that survives three constraints the rest of the economy does not face: reimbursement rules that decide whether the buyer can pay you at all, hospital procurement cycles that decide when the buyer can pay you, and device class obligations that decide how much it costs you to deliver. The five realistic options — capital sale, lease, subscription, razor-and-blade consumables, and outcome-based pricing — are not interchangeable. Each one fits a specific combination of device type, buyer economics, and reimbursement path. Pick the wrong one and the device sells at a loss for every unit. Pick the right one and the same device funds the company through its next round.

By Felix Lenhard and Tibor Zechmeister. Last updated 10 April 2026.

TL;DR

  • A MedTech business model analysis picks the revenue model that fits the device's reimbursement path, procurement cycle, and device class — not the one that looks cleanest on a pitch deck.
  • Five realistic revenue models exist for medical devices: capital sale, lease, subscription, razor-and-blade consumables, and outcome-based pricing. Each fits a specific profile. None is universally best.
  • Reimbursement is the first filter. If the payer will not fund your model, no amount of clinical enthusiasm fixes the business.
  • Hospital procurement cycles run in quarters and years, not weeks. Subscription revenue in MedTech does not behave the way SaaS founders expect.
  • Device class drives cost of delivery. A Class IIb device carries a QMS, PMS, clinical, and vigilance cost base that a Class I device does not, and the revenue model has to absorb it.
  • The most common mistake is copying a SaaS business model onto a medical device without checking whether the payer, the buyer, and the Regulation allow it.
  • MDR Article 7 constrains what you can claim about the device in any commercial material. The business model has to be defensible in language the Regulation permits.

The Graz SaaS founder who thought reimbursement would catch up

Tibor watched a founder in Graz launch a software-as-a-medical-device product with a clean SaaS subscription model. Monthly pricing. Automatic renewal. A dashboard the clinician could open from any workstation. Everything the founder had learned from the SaaS playbook, applied to a regulated device. The product was good. The clinical evidence was solid. The intended purpose was well-written and the classification under Annex VIII was defensible.

The founder had one assumption baked into the model that did not hold. They had assumed that once the clinicians liked the product, the hospitals would figure out how to pay for it — that reimbursement would catch up with the software category because the clinical value was obvious. They had seen this happen in other European markets for other SaMD categories, and they believed the Austrian sick funds would follow.

The sick funds did not follow. There was no billing code that matched the software's clinical use. The hospitals liked the product, the clinicians asked for it, but the hospital CFO had no line in the budget to fund a monthly subscription for a tool that did not produce reimbursable procedure codes. Every hospital the founder sold into had to absorb the cost against an already-allocated operational budget, and the finance department's answer, eventually, was always the same. "Come back when there is a code."

The founder burned through the runway waiting for the code that did not come. The product was not the problem. The clinical evidence was not the problem. The subscription revenue model was the problem, because it asked the hospital to pay a recurring cost for a capability that the reimbursement system did not recognise as a reimbursable capability. A different revenue model — a one-time licence tied to a capital equipment purchase, or a per-case fee bundled into an existing reimbursed procedure — might have survived the same environment. The business model, not the device, was the thing that needed to change.

That story is why this post exists. The MedTech business model analysis is not a pitch deck exercise. It is a survival exercise.

The MedTech revenue model question

The revenue model question in MedTech is narrower than founders coming from software assume. In SaaS the question is essentially open — monthly, annual, usage-based, seat-based, freemium, tiered, enterprise. Pick the one that maximises LTV over CAC and iterate. The cost of being wrong for a quarter is a quarter of lost revenue.

In MedTech the question is constrained by three things that do not move on startup timelines.

Reimbursement. If the payer does not fund the model, the model does not work. Reimbursement systems move slowly, rules are national or regional, and codes get created on timelines measured in years. A revenue model that assumes a code will exist when it does not exist today is a revenue model that dies waiting.

Procurement cycle. Hospital procurement runs on quarterly and annual budgets. Capital equipment purchases fit one cycle. Operational expenses fit another. A subscription model that requires an operational budget line the hospital has not allocated will not be bought this year, no matter how much the clinician wants it. Procurement does not rearrange itself around a startup's revenue preferences.

Device class. Your cost of delivery scales with device class. A Class I device can be built, shipped, and supported by a small team with a proportionate QMS. A Class IIb or Class III device carries a QMS, PMS, clinical evaluation, vigilance, and technical file obligation that consumes real engineering and regulatory hours every month. The revenue model has to cover that steady state, not just the first sale.

The realistic set of revenue models that fit these three constraints is small. Five options, each with a specific profile, cover almost every MedTech device on the European market.

Capital sale vs lease vs subscription

Capital sale. The hospital buys the device once, owns it, depreciates it over a defined period, and that is the end of the revenue event for that unit. The manufacturer books the revenue up front. Service contracts, consumables, or software updates can add recurring revenue on top. Capital sale fits devices that the hospital classifies as capital equipment — imaging systems, monitors, certain surgical devices, installed hardware — and that go through the capital budget cycle. The advantage is cash up front. The disadvantage is lumpy revenue, long sales cycles, and a pricing negotiation against a depreciation model the hospital already runs.

Lease. The hospital pays a recurring fee for the right to use the device, without taking ownership. Lease fits the same device types as capital sale, but shifts the cost from the capital budget to the operational budget. This matters because in many hospitals the capital budget is frozen, reviewed annually, and politically contested, while the operational budget has more headroom. A device that cannot fit into the capital cycle this year can sometimes enter under a lease arrangement. The manufacturer trades cash up front for a predictable recurring stream and the ability to refresh the device on a controlled cycle.

Subscription. The hospital pays a recurring fee for continued use, continued access, or continued service, often combined with software updates and support. Subscription fits software-as-a-medical-device and cloud-delivered services particularly well, because the underlying cost of delivery is itself recurring. The trap is the one the Graz founder fell into. Subscription only works if the buyer has an operational budget line that matches your fee and the payer is funding that line, directly or indirectly. Without reimbursement alignment, a subscription model in MedTech is an invoice the hospital cannot pay.

The choice between these three is not a preference. It is the intersection of three questions. What does the hospital's budget treat this device as — capital, operational, or not budgeted at all? What is the reimbursement path — is the device reimbursed as equipment, per-case, per-procedure, or not at all? And what is your cost of delivery — front-loaded once at sale, recurring for support, or both?

Razor-and-blade for consumables

The razor-and-blade model sells the base device at or near cost and earns margin on the consumables the device requires to function. It works when the device genuinely consumes something per use — sterile disposables, test strips, single-use cartridges, proprietary reagents, dedicated catheters — and when the consumable is technically or contractually tied to the device so the hospital cannot switch to a generic.

For a MedTech startup this model can be attractive because it turns a one-time sale into a recurring revenue stream tied directly to usage. Every procedure the device runs generates margin. The installed base compounds. The better the device performs clinically, the more the hospital uses it, and the more consumables the hospital buys.

The constraint is real. The razor-and-blade model only works if the consumable is a genuinely proprietary part of the system and if the hospital cannot substitute a third-party alternative. MDR obligations attach to every consumable that meets the device definition, which means each consumable may need its own technical documentation, conformity assessment, and vigilance chain. The cost of delivering the blades is not zero, and founders who model this as pure software-like recurring revenue miss the full regulatory bill on the disposable side.

The model also interacts with procurement. Hospitals know the razor-and-blade pattern. Procurement will push back on consumable lock-in, will ask for guaranteed consumable pricing, and will sometimes refuse to buy the base device unless the consumable pricing is capped in contract. A founder who models this without pricing-cap negotiations is modelling a world that does not exist.

SaaS subscription for SaMD

Software-as-a-medical-device is the category where subscription pricing fits most cleanly on paper and breaks most visibly in practice. The cost structure is right — software delivery is recurring by nature, updates are continuous, support is an ongoing load — and the SaaS vocabulary gives founders a mental model that feels familiar.

The break happens at the buyer side. For SaMD subscription to work, one of three things has to be true. Either the software is bundled into a reimbursed procedure code and the hospital captures revenue each time it uses the tool. Or the software replaces a cost the hospital already carries — staff time, a legacy system, a third-party tool — and the subscription fee is smaller than the replaced cost. Or the software is funded by a research grant, a pilot programme, or a non-operational budget line that the hospital has specifically allocated for innovation.

If none of those three conditions holds, the SaaS-for-SaMD model will stall at the same place the Graz founder stalled. The clinicians will ask for it. Procurement will block it. The finance director will say "come back when there is a code." The founder will interpret the delay as a sales problem and spend runway on more sales activity, when the problem is not sales but revenue model fit.

The other failure mode is misreading the procurement cycle. SaaS founders expect month-to-month signups. Hospitals do not sign up month-to-month for anything. Even a subscription product is bought on a one-year or three-year contract, renewed annually, negotiated against other line items in a budget review. The "subscription" in MedTech is often closer to an annual licence than to a SaaS self-serve flow, and the cash-flow behaviour is different enough that founders should plan for it deliberately.

Outcome-based pricing reality

Outcome-based pricing — the hospital pays more if the device produces a better clinical or economic outcome — is the revenue model that investors love and that almost nobody ships. The theory is elegant. The device is priced on the value it creates, the incentives of the manufacturer and the buyer align, and pricing pressure becomes a function of measurable results.

The practice is difficult for reasons that are not fixable by a better contract.

Outcome-based pricing requires a measurement system that both parties trust. Hospitals are cautious about signing contracts where their payment depends on a measurement the manufacturer controls. Manufacturers are cautious about signing contracts where payment depends on a measurement the hospital controls. Getting both sides to agree on a neutral, auditable outcome measure — and on who carries the cost of measuring it — is a multi-month legal and operational exercise that most startups do not have the runway for.

Outcome-based pricing also runs into reimbursement incompatibility. Most reimbursement systems pay per procedure, per device, or per admission — not per outcome. If the hospital's revenue from using the device is fixed by the billing code, a variable payment to the manufacturer eats into the hospital's margin in an unpredictable way that procurement cannot model. Hospitals will not sign contracts whose cost they cannot forecast.

This does not mean outcome-based pricing never works. It can work for devices with very clear, hospital-visible economic outcomes — readmission reduction, length-of-stay reduction, complication-rate reduction — where the hospital is already measuring the outcome for its own reasons and the contract simply references the hospital's own data. It can also work with large integrated payers who are willing to run pilot programmes and bear the measurement cost. For a MedTech startup, it is almost never the first revenue model. It is a second or third evolution, introduced years after the base model is established.

The reimbursement constraint

Reimbursement is the filter that kills revenue models before any other consideration matters.

Before committing to a revenue model, answer three questions for every target market.

Is the device reimbursed at all? In the target country, is there a billing code, a DRG weighting, a tariff entry, or a fund category that pays the hospital for using your device? If the answer is no, the revenue model has to survive on the hospital's own budget with no external revenue capture, which is possible but narrow.

Who actually pays? Statutory sick funds. Private insurers. National health services. Ministries of health. Regional health authorities. Out-of-pocket patients. The identity of the payer changes the sales motion and the evidence they will require before they fund the model.

What does the reimbursement fund — the device, the procedure, the software, the outcome? A device reimbursed as capital equipment fits a capital sale model. A device reimbursed per procedure fits a razor-and-blade or per-case model. A software tool whose value is bundled into a procedure code can fit a subscription, as long as the procedure is run often enough. A capability with no funded category at all does not fit a recurring-revenue model no matter how attractive it looks on the pitch deck.

The reimbursement answer has to come before the revenue model decision, not after. Founders who pick the revenue model first and then hope reimbursement catches up are the founders who run out of money in the category gap.

The cost-of-delivery reality

Revenue is only half of the model. The other half is what it costs you to deliver each unit at steady state, and the MedTech steady state is heavier than founders from other industries expect.

The cost of delivery for a medical device includes the variable cost of the physical product or the hosting infrastructure, plus a steady share of the regulatory cost base that scales with class. QMS maintenance, PMS data collection and reporting, vigilance processing, PSUR writing, clinical evaluation updates, technical file maintenance, Notified Body surveillance fees, PRRC time, and cybersecurity monitoring all consume hours every month, and those hours belong on the cost-of-delivery line, not the one-time R&D line.

A revenue model that looks profitable on a unit basis at launch can quietly turn unprofitable at steady state if the ongoing regulatory burden was not modelled. A capital sale at EUR 30,000 per unit is a different business than a capital sale at EUR 30,000 per unit that carries EUR 8,000 per year in allocated regulatory maintenance per installed device. A subscription at EUR 500 per month per seat is a different business if the per-seat share of PMS, vigilance, and Notified Body fees eats EUR 200 of it.

The discipline is to model the full steady-state cost of delivery per unit, per year, before picking the revenue model. If the honest number does not support the model, either change the model, raise the price, cut the scope, or stop. "We will figure out the cost side later" is how MedTech startups die profitable-looking deaths.

A shrimp farm, a razor-and-blade model, and the lesson that still applies

One of Felix's clearest lessons about business model fit came from a domain very far from MedTech. A founder he worked with built a shrimp farming operation and arrived convinced the revenue model was the product itself — selling shrimp. Felix walked him through the numbers. Selling shrimp at commodity prices against large incumbents, with a variable cost base the founder could not control and a delivery chain that did not favour small producers, was a business that could not survive the first bad quarter.

The rescue was a business model change, not a product change. Instead of selling shrimp, the business model shifted to selling the system — the equipment, the know-how, the starter stock, the training — to other people who wanted to run their own shrimp farms. The margin was no longer in the commodity. The margin was in the recurring consumables and inputs the new operators needed to keep their farms running, and in the services that supported them. The product did not change. The business model did, and the business became viable.

The lesson transfers directly to MedTech. Founders fall in love with the device and believe the revenue model is an afterthought. "We will sell the device for X, the market will pay X, and everything else will follow." That is almost never how it works. The device is the product. The revenue model is a separate design problem, and in MedTech the revenue model is constrained by forces the founder did not create — reimbursement, procurement cycles, device class — and has to be designed against those constraints, not against a clean pitch deck. A good MedTech business plan treats the revenue model as a first-class engineering artefact, tested against the real buyer economics the way the device itself is tested against the GSPR.

Common mistakes

  • Copying the SaaS subscription model onto a SaMD product without checking reimbursement. The Graz founder above. The most common and most expensive mistake in MedTech revenue model selection.
  • Modelling the cost of delivery as variable only, ignoring the regulatory steady-state cost. Every installed device carries a share of the ongoing QMS, PMS, vigilance, and Notified Body burden. Leave it out of the model and the unit economics look better than they are.
  • Picking razor-and-blade without modelling the blade's own MDR obligations. Consumables are often medical devices in their own right. Each one carries its own technical documentation, conformity assessment, and vigilance obligations. The blade is not a trivial add-on.
  • Assuming reimbursement will catch up. Sometimes it does. Usually it does not on the timeline a startup can survive. Build the model on the reimbursement that exists today, not on the reimbursement you hope exists in three years.
  • Picking outcome-based pricing because it sounds attractive to investors. It is almost never the first revenue model that ships. Treat it as a later evolution, not a starting point.
  • Writing commercial materials that claim more than the intended purpose allows. Under MDR Article 7, it is prohibited to use text, names, trade marks, pictures, and figurative or other signs in the labelling, instructions for use, making available, putting into service, and advertising of devices that may mislead the user or patient about intended purpose, safety, and performance. (Regulation (EU) 2017/745, Article 7.) Every revenue model lives inside the boundary of what Article 7 permits you to say about the device. A pricing argument that relies on claims outside that boundary is a pricing argument that cannot survive audit.
  • Treating procurement cycles as a marketing problem. They are not. They are an arithmetic constraint on when cash can arrive.
  • Ignoring the difference between public and private hospital revenue dynamics. The same device at the same price sells differently into a public tender environment than into a private clinic. Model both.

The Subtract to Ship angle

Every element of the revenue model should trace back to either a specific reimbursement reality, a specific procurement cycle, a specific device class cost, or a specific MDR obligation. If an element cannot be traced to one of those four, it is drag — an assumption that has no mechanism to be true in the world the buyer actually lives in.

The subtraction is direct.

  • Every revenue line in the model should reference a real payer, a real code or budget category, and a real hospital conversation that confirmed the category exists today.
  • Every cost line in the model should include the full steady-state regulatory burden at the device's actual class, not the optimistic version.
  • Every pricing claim should fit inside the intended purpose and the constraints of MDR Article 7. If a pricing argument requires a claim the Regulation does not allow, the argument does not survive first contact with a regulator or a competitor complaint.
  • Every revenue model the founder is tempted by because it "worked somewhere else" should be run through the reimbursement, procurement, and class filters before any slide is written.
  • Every feature of the device that does not move the revenue model into a better category should be scrutinised against the Purpose Pass described in the Subtract to Ship framework for MDR.

Read the decision-making units in MedTech sales post for the companion view on who the revenue model has to convince, and the MedTech value chain for the map of every seat that takes a cut along the way.

Reality Check — where do you stand on your MedTech business model?

Answer these honestly. If more than two are weak, the revenue model is not ready to commit to.

  1. Can you name the revenue model you are betting on — capital sale, lease, subscription, razor-and-blade, or outcome-based — and the specific reason it fits your device?
  2. For the target market, do you know today whether your device is reimbursed, under which code or category, and whether the code already exists or is hypothetical?
  3. Have you modelled the full steady-state cost of delivery per unit per year, including the share of QMS, PMS, vigilance, clinical, and Notified Body costs?
  4. Do you know whether the hospital will treat the purchase as capital or operational spend, and have you matched your revenue model to the right budget line?
  5. If your revenue model is subscription or lease, do you know the actual procurement cycle at your target buyers and when the next decision window opens?
  6. If your revenue model is razor-and-blade, have you counted the MDR obligations on the consumable as well as on the base device?
  7. Is every pricing claim and commercial statement defensible under MDR Article 7 and inside your written intended purpose?
  8. If reimbursement stayed exactly as it is today for the next three years, would your business model still work?
  9. Have you tested the model against a real buyer conversation with a named hospital, not against an internal slide deck?
  10. If you had to pivot the revenue model tomorrow without changing the device, do you know which of the other four options the device could support?

Frequently Asked Questions

What is the right business model for a MedTech startup? There is no single right answer. The right MedTech business model is the one that fits three constraints: the reimbursement path for the device in the target market, the hospital's procurement cycle and budget category, and the steady-state cost of delivery at the device's MDR class. Five realistic options exist — capital sale, lease, subscription, razor-and-blade consumables, and outcome-based pricing — and each one fits a specific combination of those constraints. The analysis starts with reimbursement, then procurement, then cost of delivery.

Can SaaS subscription pricing work for a medical device? Yes, but only when the subscription fee maps to a buyer economic the hospital can fund — a reimbursed procedure the software supports, a replaced cost the software eliminates, or a dedicated innovation budget. Without one of those conditions, a SaaS subscription model for a SaMD product stalls at procurement even when the clinicians ask for it. The Graz SaMD founder Tibor watched lost runway to this exact failure pattern.

Why is razor-and-blade pricing common in MedTech? Because it turns a one-time capital event into a recurring revenue stream tied to actual device usage, which is closer to the value the hospital experiences. The constraint is that the blade has to be a genuinely proprietary part of the system, the hospital cannot substitute a third-party alternative, and every consumable that qualifies as a medical device carries its own MDR obligations. The model works when the base device and the consumable are designed together and the full regulatory burden on both sides is in the model.

Does outcome-based pricing work for medical devices? Sometimes, and almost never as a first revenue model for a startup. Outcome-based pricing requires a trusted measurement system both parties accept, a reimbursement environment that can accommodate variable manufacturer payments, and a buyer sophisticated enough to model the contract. Most startups lack the runway to build those conditions. Outcome-based pricing is a second or third evolution after a conventional model is established, not a starting point.

How does MDR device class affect my business model? Device class drives the cost of delivery. A Class I device has a proportionate QMS, limited clinical evaluation requirements, and no Notified Body surveillance fees in most cases. A Class IIa, IIb, or III device carries a QMS, PMS, clinical evaluation, vigilance, and Notified Body surveillance burden that consumes real hours every month and belongs on the unit cost line. A revenue model that ignored the class-driven steady-state cost looks better than it is.

What does MDR Article 7 have to do with pricing? MDR Article 7 prohibits misleading claims in labelling, instructions for use, advertising, and commercial materials about the device's intended purpose, safety, and performance. Every pricing argument a founder makes about a device lives inside that boundary. A revenue model that depends on claims Article 7 does not permit — for instance, claims of benefits beyond the intended purpose — is a revenue model that cannot survive regulator or competitor scrutiny. Pricing is a regulatory surface, not just a commercial one.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, consolidated text. Article cited: Article 7 (claims). Official Journal L 117, 5.5.2017.
  2. Regulation (EU) 2023/607 of the European Parliament and of the Council of 15 March 2023 amending Regulations (EU) 2017/745 and (EU) 2017/746 as regards the transitional provisions for certain medical devices and in vitro diagnostic medical devices. Official Journal L 80, 20.3.2023.

This post is part of the MedTech Startup Strategy and PMF series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The device is the product. The revenue model is a separate design problem, and in MedTech it is constrained by reimbursement, procurement cycles, and device class. Design the model against those constraints, not against a pitch deck.