How to start an ai company?

Start with a clinical problem that has a buyer (not just a model)

Most first-time founders start with “we can build an AI that detects X.” Hospitals don’t buy “AI.” They buy outcomes: fewer adverse events, faster throughput, lower costs, better documentation, or higher quality scores. Your first job is to define a clinical use case that maps to a budget owner and a measurable economic outcome.

Use this simple framing:

• User: who touches it daily (radiologist, ED physician, nurse, coder, care manager)?
• Buyer: who signs (department chair, CMIO, CFO, revenue cycle, value-based care team)?
• Workflow slot: where it lives (PACS, EHR, triage queue, discharge planning, coding)?
• Outcome metric: time-to-treatment, LOS, readmissions, denial rate, RVUs, complication rate.

Pick a wedge that is narrow enough to validate quickly but valuable enough to expand. Examples of good wedges in medtech AI often include: reducing radiology turnaround time, automating prior auth documentation, predicting deterioration for rapid response, or improving coding accuracy—because each has a clear operational or financial owner.

Define your product as “software as a medical device” (SaMD) or not

In medtech, the same model can be regulated or not depending on claims and intended use. If your software diagnoses, treats, or drives clinical decisions, it may be considered Software as a Medical Device (SaMD). If it’s purely administrative (e.g., scheduling optimization) it may be non-device software.

Write a one-paragraph Intended Use statement early. It will drive everything: data needs, validation, FDA pathway, and sales cycle.

Choose a likely FDA pathway (510(k), De Novo, PMA)

Don’t guess—treat this as a hypothesis you validate with a regulatory consultant and by studying predicate devices (similar cleared products). High level:

• 510(k): you show your device is substantially equivalent to a legally marketed predicate. Common for many imaging AI tools.
• De Novo: for novel, low-to-moderate risk devices without a predicate. Often used when your claim is new.
• PMA: for higher-risk devices; evidence burden is heavier.

Also decide whether you will be clinical decision support (CDS) that keeps a human “in the loop” with explainable rationale, or whether you’re making autonomous outputs. That choice affects risk, regulatory burden, and adoption.

Data strategy: access, rights, labeling, and generalization

AI companies die from “data optimism.” You need a plan for (1) getting data legally, (2) labeling it reliably, and (3) proving it works across sites.

Get data the hospital can actually share

Hospitals care about HIPAA, security reviews, and contractual risk. Expect a long lead time. Common routes:

• Retrospective datasets under a data use agreement (DUA). If you need identifiable data, you’ll likely need additional controls.
• Prospective study with IRB approval (Institutional Review Board) if you’re collecting data for research or testing in a way that constitutes human subjects research.
• On-prem / VPC deployment so data doesn’t leave the health system (often speeds approvals).

Be explicit about what you need: modality, time window, inclusion/exclusion criteria, and what “ground truth” means. For example, “sepsis” labels based on ICD codes can be noisy; clinician-adjudicated labels are cleaner but expensive.

Labeling and evaluation: design it like a clinical study

Even before FDA, you should run your development like a mini clinical program:

1. Define endpoints: sensitivity/specificity, AUROC, time saved, false alert rate per patient-day, etc.
2. Pre-specify cohorts: avoid “we’ll see what works.”
3. External validation: at least one site different from training data to test generalization.
4. Human factors: how clinicians interpret outputs; what happens when they disagree.

In hospital AI, alert fatigue is a product killer. A model with great AUROC can still fail if it generates too many low-value alerts. Track operational metrics early (alerts per shift, override rate, time-to-action).

Build the business model around reimbursement and procurement reality

Medtech AI is constrained by two systems: reimbursement (how money flows) and procurement (how hospitals buy). Your pricing must fit both.

Reimbursement: CPT codes, DRGs, and value-based care

Reimbursement jargon, translated:

• CPT code: billing code for a service (often physician/outpatient). If your product enables a billable service, adoption can be easier.
• DRG: bundled payment for inpatient stays. If you reduce length of stay or complications, the hospital may benefit financially.
• Value-based care: contracts where providers are rewarded for outcomes and cost reduction; AI that prevents readmissions can be attractive.

You don’t need a brand-new CPT code to build a company, but you do need a credible value story. Example: “We reduce denials by improving documentation” ties directly to revenue cycle. “We improve diagnostic accuracy” may require stronger clinical evidence and faces longer sales cycles.

Procurement: security, integration, and the “who owns the pain?” question

Hospital procurement is a multi-stakeholder process. Expect: security review, legal, compliance, clinical champion, IT integration, and budget approval. Design for this:

• Integration: EHR (often via HL7/FHIR), PACS, or existing workflow tools.
• Deployment: cloud vs on-prem; many systems prefer a controlled environment.
• Pricing: per site, per study, per bed, per user, or outcomes-based (harder but compelling).

Pick a buyer persona and build the ROI case in their language. A CMIO cares about clinician experience and safety; a CFO cares about margin and risk; radiology leadership cares about throughput and RVUs.

Go-to-market: prove value with pilots, then scale with a repeatable motion

For a first product, your goal is not “sell to 100 hospitals.” Your goal is one repeatable sales narrative that works across similar hospitals.

Pilot design that converts to paid

Many pilots fail because they’re “science projects.” Structure a pilot like a commercial contract:

• Timeline: 60–120 days is common for operational pilots (varies by integration).
• Success criteria: pre-agreed metrics (e.g., reduce time-to-read by X%, reduce denials by Y%).
• Data access: what you can use for model improvement and publication (if any).
• Conversion clause: pricing and decision date if metrics are met.

Also decide your initial market: academic medical centers (innovative but slow) vs community hospitals (faster decisions but fewer resources) vs imaging groups (different incentives). There isn’t one right answer—choose the segment where your workflow fit and buyer urgency are strongest.

Team: the minimum viable founding group for medtech AI

In medtech, credibility and execution matter as much as code. A strong early team often includes:

• Clinical lead (MD/DO/RN) who owns workflow truth and clinical validation.
• ML/engineering lead who can ship reliable systems, not just notebooks.
• Regulatory/quality owner (can be fractional early) to set up design controls and documentation.
• Commercial lead (or founder-led sales) who can run pilots and navigate procurement.

If you’re technical, don’t outsource the clinical truth. If you’re clinical, don’t outsource the product thinking. The best medtech AI founders learn enough of the other side to make fast, correct decisions.

What to do next

1. Write your one-paragraph Intended Use and list 3–5 measurable outcomes (clinical + economic) tied to a specific buyer.
2. Interview 15–20 target users and 5–10 buyers to validate workflow slot, integration constraints, and what they would pay for.
3. Draft a pilot plan with success metrics, timeline, and conversion pricing; use it to recruit your first clinical site.
4. Map a preliminary FDA pathway (510(k) vs De Novo vs PMA) and identify likely predicates; engage a regulatory advisor to sanity-check.
5. Build a data access plan (DUA/IRB, de-identification, deployment model) and a labeling strategy that matches your endpoints.

If you want structured feedback on your use case, positioning, and go-to-market, run it through our tools and templates.