How does startup work?

A startup is not “a small company.” It’s a system for turning uncertainty into evidence until you find a business model that can grow. In medtech, the uncertainty is bigger because you’re not only proving that a product works—you’re proving it can be regulated, reimbursed, purchased, and used safely in real clinical workflows.

Think of a startup as a loop:

• Hypothesis (who has what problem, and why they’ll pay)
• Test (build the smallest credible solution and validate it)
• Learn (what’s true, what’s false, what changed)
• Iterate (adjust product, market, pricing, or pathway)

Below is how that loop typically plays out in a medtech startup from idea to scale.

1) The core engine: problem → value → business model

Most first-time founders start with a technology. Startups win by starting with a painful, frequent, expensive problem and mapping it to a buyer.

Define the “who” precisely (user ≠ buyer ≠ payer)

In healthcare, these roles often differ:

• User: clinician, nurse, tech, patient—who touches the product.
• Buyer: hospital department, supply chain/procurement, IDN, ASC administrator.
• Payer: insurer/government; or the hospital itself under bundled payments.

Your startup “works” when you can clearly answer: Who benefits, who pays, and why now? A common failure mode is building something clinicians like but procurement won’t buy, or something hospitals buy but payers won’t reimburse.

2) Validation: prove demand before you overbuild

Validation is gathering evidence that your solution is worth adopting. In medtech, you need to validate clinical workflow fit, economic value, and risk/regulatory feasibility early.

Customer discovery (structured interviews)

Run 20–50 interviews across at least three groups: end users, economic buyers, and stakeholders (biomed, IT/security, compliance, infection control, revenue cycle). Your goal is not “feedback,” it’s decision criteria:

• What triggers the purchase (sentinel event, new guideline, staffing shortage)?
• What budget line item would fund it (capex vs opex, departmental vs central)?
• What would block it (IT integration, training time, liability concerns)?
• What outcome matters (LOS, readmissions, complications, throughput)?

Define a Minimum Viable Product (MVP) for medtech

MVP in medtech is not “a buggy app.” It’s the smallest version that can credibly test adoption and outcomes without creating unacceptable risk. Examples:

• A non-integrated prototype used in simulated workflow to measure time saved.
• A clinical decision support tool deployed in “silent mode” to compare predictions vs outcomes.
• A benchtop prototype that demonstrates performance against a known predicate device.

If humans are involved, you may need IRB approval for certain studies. Plan for this early; it affects timelines and what claims you can make.

3) The medtech constraint: regulatory + quality + clinical evidence

Unlike many software startups, medtech startups must align product design with a regulatory pathway and a quality system. This is not paperwork for later—it shapes what you build.

Regulatory pathway (high-level)

• 510(k): you show “substantial equivalence” to a predicate device. Often faster/cheaper than novel pathways, but depends on finding a good predicate and matching intended use.
• De Novo: for novel, low-to-moderate risk devices without a predicate. More evidence burden than many 510(k)s, but can create a new device classification.
• PMA: for high-risk devices; typically requires robust clinical evidence and is the most demanding pathway.

Digital health may still be regulated as Software as a Medical Device (SaMD) depending on claims and risk. The practical takeaway: your marketing claims determine your regulatory burden. “Helps clinicians prioritize” is different from “diagnoses.”

Quality system and design controls

To sell into serious clinical environments (and to survive diligence), you’ll need a quality management approach (often aligned with ISO 13485) and design controls (requirements, verification/validation, risk management). Even if you’re pre-revenue, investors and strategic partners will ask: “Is this build traceable and auditable?”

4) Getting paid: reimbursement, procurement, and go-to-market

A medtech startup works economically only when there is a repeatable path to revenue. In healthcare, revenue is constrained by reimbursement and purchasing processes.

Reimbursement basics (CPT/HCPCS/DRG)

• CPT codes: billing codes used for physician services and many procedures. If your product enables a billable service, adoption can be easier.
• HCPCS: often used for devices, supplies, and some services.
• DRG: hospital inpatient payment bundles; hospitals care about margin within the bundle (cost reduction, complication avoidance, throughput).

If there’s no clear reimbursement path, you may need a value story based on cost savings (e.g., fewer complications, shorter length of stay) or new revenue (e.g., enabling a reimbursable procedure). Exact coverage and payment varies by payer and setting.

Hospital procurement reality

Even with clinical champions, hospitals often require:

• Security review (especially for connected devices and software)
• Integration planning (EHR, device connectivity, data governance)
• Value analysis committee approval
• Contracting and vendor onboarding

This is why early pilots should be designed not only to prove clinical outcomes, but also to reduce perceived implementation risk.

Go-to-market (GTM) options

• Direct sales: higher control, slower ramp, requires sales talent and long cycles.
• Channel/strategic partners: faster access, lower margin, requires partner-ready evidence and integration.
• Land-and-expand: start with one department/site, then expand across service lines or facilities.

In medtech, a “startup that works” typically has a repeatable pilot-to-contract motion: you can predict what a pilot costs, how long it takes, what success metrics convert to purchase, and who signs.

5) Funding and scaling: why startups raise money (and what investors look for)

Startups raise money to buy time and talent to reach the next value-inflection milestone—a point where risk drops and valuation rises. In medtech, milestones are often tied to evidence and approvals, not just user growth.

Common medtech milestones (examples)

• Prototype performance data (bench/animal as appropriate)
• Regulatory strategy locked (pathway, intended use, predicate or De Novo plan)
• First clinical data (pilot feasibility, usability, safety signals)
• Quality system foundations (design controls, risk management)
• Reimbursement strategy (existing codes vs pathway to coverage)
• Signed LOIs or paid pilots with clear conversion criteria

Investors typically underwrite three risks:

1. Technical/clinical risk: does it work and is it safe?
2. Regulatory risk: can it be cleared/approved for the claims you need?
3. Commercial risk: will someone pay, and can you sell repeatedly?

A startup “works” when you systematically retire these risks faster than you burn cash.

What to do next

1. Write a one-page “who/user/buyer/payer” map for your medtech idea and list the top 10 assumptions that must be true.
2. Run 15 customer discovery interviews (5 users, 5 buyers, 5 stakeholders) and document decision criteria and blockers.
3. Draft a regulatory and evidence plan: intended use, likely 510(k)/De Novo/PMA direction (or “not a device” rationale), and what data you need first.
4. Design a pilot with conversion metrics (e.g., time saved, complication reduction proxy, adherence, throughput) and define who signs if it succeeds.
5. Build a simple financial model with your expected pilot cost, sales cycle length, and pricing hypothesis to see what must be true for sustainability.

If you want structured feedback on your positioning and pathway, use /roast or map competitors and predicates with /Competitor_study.