How to start your own ai company?

Start with a clinical wedge, not a model

Most first-time founders start with “we’ll build an AI that does X.” In medtech, the winning sequence is the opposite: pick a painful, frequent, and measurable clinical workflow problem, then decide whether AI is the right tool.

A good “wedge” use case has three properties:

• Clear user: the person who clicks the button (radiologist, ED physician, nurse, care manager).
• Clear economic buyer: the person who signs (department chair, CMIO, value analysis committee, payer, or health system CFO).
• Clear measurable outcome: time saved, reduced length of stay, fewer readmissions, fewer adverse events, improved sensitivity/specificity, or improved throughput.

Examples of wedges that are often easier than “diagnose everything”:

• Worklist triage (prioritize studies likely to be critical) rather than final diagnosis.
• Quality/safety checks (missing documentation, contraindications, dosing checks) rather than autonomous decisions.
• Operational prediction (no-show risk, bed demand) where the output is a planning signal, not a clinical order.

Before writing code, do 20–30 structured interviews. Your goal is to map: current workflow, failure points, who feels the pain, what “good” looks like, and what would make them switch. If you want a template for this, use /interviews.

Decide what you’re building: SaMD vs. non-device AI

In medtech, “AI company” can mean two very different businesses:

• Software as a Medical Device (SaMD): software intended to diagnose, treat, mitigate, or prevent disease. This often triggers FDA oversight.
• Non-device clinical software: workflow, operations, documentation, billing support, or research tools that may not be regulated as a medical device (depending on claims and functionality).

This distinction matters because it changes your timeline, cost, evidence requirements, and go-to-market (GTM). If you’re making clinical claims, assume you’ll need a regulatory strategy from day one.

Pick a plausible FDA pathway early

For many AI-enabled SaMD products, the common FDA pathways are:

• 510(k): you show “substantial equivalence” to a legally marketed predicate device. Often the fastest if a close predicate exists.
• De Novo: for novel, low-to-moderate risk devices without a predicate. More work than 510(k), but establishes a new device type.
• PMA (Premarket Approval): for high-risk devices; typically the most burdensome evidence-wise.

Don’t guess. Do a lightweight predicate scan and claims analysis. Your marketing language (“detects,” “diagnoses,” “rules out,” “recommends treatment”) can change the regulatory classification. If you need help pressure-testing your positioning, run it through /roast.

Data strategy: access, rights, and clinical truth

In medtech AI, the model is rarely the bottleneck. The bottlenecks are data access, label quality, and deployment reality (integration, drift, monitoring).

Get the data legally and operationally

Common sources include health systems, imaging centers, registries, and device manufacturers. You need to clarify:

• Data rights: who owns the data, what you can do with it, and whether you can use it for commercial product development.
• Privacy and security: HIPAA compliance, de-identification where appropriate, and security controls that pass hospital review.
• IRB approval: if you’re doing prospective studies or using identifiable data for research, you may need IRB oversight. Requirements vary by institution and study design.

Also plan for the “last mile”: hospitals will ask about SOC 2, penetration testing, audit logs, role-based access, and data retention. You don’t need enterprise perfection on day one, but you do need a credible roadmap.

Define ground truth and clinical utility

“Accuracy” is not a business outcome. Define:

• Ground truth: radiology report? pathology? adjudicated panel? follow-up outcomes? Each has tradeoffs.
• Target metric: sensitivity/specificity, PPV/NPV, AUROC, time-to-intervention, alert burden, or avoided downstream tests.
• Clinical utility: what action changes because of the model output, and what harm occurs if it’s wrong?

Design your product so the output fits the workflow (e.g., a triage flag in PACS/RIS, a note suggestion in the EHR, or a queue for care managers). If the user has to open a separate dashboard, adoption usually suffers.

Business model: reimbursement, procurement, and who pays

Medtech AI is sold into complex systems. Your business model must match how money moves.

Reimbursement: CPT codes and value story

If your product is tied to billable clinical services, you need a reimbursement plan. That may involve:

• CPT codes: whether existing codes apply, whether your tool supports documentation for billing, or whether new coding pathways are needed (often difficult and slow).
• Payer value: reduced admissions, fewer complications, better risk adjustment, or improved quality metrics.
• Provider value: throughput, reduced burnout, fewer missed findings, or reduced malpractice exposure (be careful with claims).

Many early-stage AI companies succeed first with a department-level ROI (e.g., radiology turnaround time) before tackling payer reimbursement. Reimbursement specifics vary widely by specialty and setting, so validate with billing experts and hospital finance early.

Hospital procurement: expect a long sales cycle

Even with a champion, hospital sales often involve:

• Clinical validation (does it work here?)
• IT/security review (risk, integration, uptime)
• Legal (BAA, liability, data use)
• Value analysis committee (cost vs. benefit)

Plan for pilots that convert. A good pilot has: a defined population, a baseline, success metrics, a timeline, and a pre-agreed decision rule (“if we hit X, we buy”). Avoid “science projects” with no purchasing path.

Build the minimum product that can be validated in the real world

In medtech AI, “MVP” (minimum viable product) should mean minimum viable evidence + workflow integration, not just a model notebook.

What to build first

• Workflow integration: where the user already works (EHR, PACS, LIS). If full integration is heavy, start with a lightweight bridge, but show the path to production.
• Human-in-the-loop design: clear UI, explanation appropriate to the user, and safe failure modes.
• Monitoring: basic telemetry, performance tracking, and a plan for model drift (data changes over time).

Also decide early whether you’re a product company (repeatable software) or a services-heavy company (custom models per site). Services can fund you early, but they can also trap you in one-off deployments. Aim for a repeatable core with configurable edges.

Team: the minimum set of roles

You don’t need a huge team, but you do need coverage of:

• Clinical: domain expertise, workflow credibility, study design.
• ML/engineering: data pipelines, model development, deployment, MLOps.
• Regulatory/quality: QMS thinking, documentation discipline, risk management.
• Commercial: discovery, pricing, procurement navigation.

If you’re a clinician-founder, pair with a strong technical cofounder (or vice versa). If you’re both technical, bring in someone who has sold into hospitals before.

What to do next

1. Choose one wedge use case and write a one-page “clinical + economic” problem statement: user, buyer, workflow, measurable outcome, and why now.
2. Run 20–30 interviews with clinicians, IT/security, and a procurement/value analysis stakeholder; capture switching criteria and pilot requirements. Use /interviews.
3. Draft your regulatory and claims strategy: decide whether you’re SaMD, and map a likely FDA pathway (510(k), De Novo, or PMA). Pressure-test your positioning with /roast.
4. Design a pilot that converts: baseline metrics, success thresholds, timeline, and a pre-agreed purchase decision rule. Model the unit economics in /finances.
5. Study the competitive landscape (including “do nothing” and incumbent workflows) and identify your differentiation wedge using /Competitor_study.