How to start up ai business?

Start with a clinical wedge, not “AI”

Most first-time founders start with a model (“we built an LLM” or “we can detect X on imaging”) and then hunt for a problem. In medtech, that usually fails because hospitals don’t buy “accuracy”—they buy workflow impact, risk reduction, or revenue protection. Your job is to pick a clinical wedge: one narrow, painful use case where a specific buyer has budget and urgency.

Use this simple wedge filter:

• High-frequency workflow: happens daily/weekly (e.g., triage, documentation, prior auth, scheduling, imaging reads).
• Clear economic owner: department chair, service line leader, revenue cycle, quality/safety, or IT/security.
• Measurable outcome: time saved per case, reduced length of stay, fewer denials, fewer adverse events, improved throughput.
• Data feasibility: you can access the right inputs (EHR, PACS, device signals) with realistic permissions.

Concrete examples of good wedges:

• Radiology: worklist prioritization for suspected critical findings (operational value even before “diagnosis”).
• Cardiology: automated echo measurement assistance (time + standardization).
• Inpatient medicine: sepsis risk alerts are crowded; a better wedge might be nursing task prioritization or handoff summarization with clear time savings.
• Revenue cycle: AI that reduces claim denials by improving documentation specificity (buyer: CFO/revenue cycle).

Validate the business before you build: buyer, workflow, and ROI

In medtech, “validation” is not a survey. It’s evidence that (1) a buyer will pay, (2) the product fits clinical workflow, and (3) you can deploy inside hospital constraints. Do these in parallel.

1) Identify the buyer and the budget line

A buyer is the person who can say “yes” and has access to budget. A champion is the clinician who loves it. You need both, but they’re often different people.

Ask in interviews:

• “What budget would this come from—IT, department ops, quality, or revenue cycle?”
• “Who signs the contract and who blocks it (security, compliance, clinical leadership)?”
• “What would you stop paying for to fund this?”

2) Map the workflow and failure modes

Write a one-page workflow map: where the data originates, who touches it, what decisions are made, and what happens when the AI is wrong. In regulated healthcare, your “edge cases” are not rare—they are where risk lives.

Practical tip: define the product as decision support (recommendations) vs automation (actions). Automation is harder to sell and often harder to regulate.

3) Build an ROI story with simple math

Hospitals respond to a clear ROI (return on investment) narrative. Keep it concrete:

• Time savings: minutes saved per case × cases per month × loaded hourly cost.
• Throughput: extra procedures per week × contribution margin (varies by hospital).
• Denials reduction: fewer denied claims × average claim value (varies).
• Risk reduction: harder to quantify, but can be framed as avoiding sentinel events and improving quality metrics.

If you can’t express value in one of these buckets, you likely have a “cool demo” rather than a business.

Decide early: is this regulated software (SaMD) and what’s the FDA path?

Many AI products in medtech are SaMD (Software as a Medical Device): software intended to diagnose, cure, mitigate, treat, or prevent disease. If your AI influences clinical decisions (e.g., flags pathology, predicts deterioration, recommends therapy), assume you may need FDA clearance/approval.

Common FDA pathways you’ll hear:

• 510(k): you show your device is “substantially equivalent” to a legally marketed predicate device. Often the fastest route when a close predicate exists.
• De Novo: for novel, low-to-moderate risk devices with no predicate. Creates a new device type that future 510(k)s can reference.
• PMA (Premarket Approval): for higher-risk devices; typically the most evidence-heavy.

What to do as a founder (without pretending to be a regulatory expert):

1. Write an “intended use” sentence (who, what, where, why). Tiny wording changes can shift regulatory burden.
2. List clinical claims you want to make (e.g., “detects,” “diagnoses,” “triages,” “assists”). Stronger claims usually mean more evidence.
3. Do a predicate scan (competitors and cleared products) to estimate whether 510(k) is plausible.
4. Plan evidence generation: retrospective study, prospective observational, or interventional—depends on risk and claim.

Also plan for quality management early. Even if you start with pilots, hospitals and regulators will expect disciplined processes for data handling, model updates, cybersecurity, and post-market monitoring.

Reimbursement and procurement: how hospitals actually buy AI

Even with FDA clearance, you still need a path to money. In medtech, that’s usually one of three routes:

• Hospital operational budget: you sell cost savings (time, staffing, length of stay). Often the fastest early path.
• Revenue lift: you enable more billable services or reduce denials. Buyer is often finance/revenue cycle.
• Reimbursement (CPT codes): you align with existing CPT codes or pursue new coding pathways (slow and uncertain). CPT codes are billing codes used for clinician services; whether your product is reimbursed depends on payer policies and clinical adoption.

Procurement realities to design for:

• Security review: expect questions on PHI handling, encryption, access controls, and vendor risk management.
• Integration: EHR/PACS integration can dominate timelines. A “works in the browser” MVP may be fine for pilots, but long-term you’ll need a credible integration plan.
• Clinical governance: committees may review AI tools for bias, safety, and monitoring.

Pricing models that commonly work early:

• Per site / per department subscription (simple for budgeting).
• Per study / per use (aligns with volume; can be harder to forecast).
• Value-based (share of savings): attractive in theory, hard to measure and slow to contract.

Build the MVP like a clinical product: data, studies, and deployment

Your first version should prove clinical utility (it helps in real workflow), not just model performance. Accuracy metrics alone rarely close deals.

Data access and IRB: don’t improvise

If you’re using patient data, you’ll likely need a compliant path: de-identified datasets, data use agreements, and sometimes IRB approval (Institutional Review Board) for research involving human subjects. Whether IRB is required depends on your study design and institution—plan for it rather than hoping it won’t come up.

Design your evidence in stages

1. Retrospective feasibility: show the signal exists and define failure modes.
2. Silent prospective: run in the background to measure performance on current data without influencing care.
3. Workflow pilot: measure time saved, adoption, and downstream outcomes (as feasible).

In each stage, predefine what “success” means (e.g., adoption rate, alert acceptance, time-to-action). This becomes your sales proof later.

Deployment: start narrow, then harden

For early pilots, you can often start with a narrow deployment (one unit, one modality, one clinic). But design for the end state:

• Monitoring: drift detection, performance dashboards, and incident response.
• Model updates: a controlled process (especially important if updates could change clinical behavior).
• Human factors: clear UI, explainability where needed, and safe defaults.

A useful mental model: you’re not shipping a model; you’re shipping a clinical system.

What to do next

1. Pick one wedge: write a one-paragraph intended use + buyer + workflow + ROI hypothesis.
2. Run 15 buyer interviews (not just clinicians): include procurement/IT/security and a budget owner; document budget source and deal blockers.
3. Draft your regulatory snapshot: SaMD or not, likely FDA pathway (510(k)/De Novo/PMA), and the minimum evidence you’ll need (varies).
4. Design a pilot plan: define success metrics, data access path, and whether IRB is needed; aim for a silent prospective or limited workflow pilot.
5. Build the smallest deployable product: integration-light but security-conscious, with monitoring and a clear clinical “human-in-the-loop” workflow.

If you want a structured way to pressure-test your wedge, pricing, and go-to-market, use the tools below.