Code Red: Why Your AI Health Startup Will Fail (And How to Fix It)
Breaking Into Healthcare: The Insider's Guide for Founders
By Iqra Aftab, MD
with valuable insights from Sumanth Kaja, MD and Erick Enriquez (YC, InQuery)
1. Why I wrote this guide
This playbook condenses the experience of two practicing MDs and a YC backed healthtech founder into a 10-minute read. Consider it your shortcut to years of hard-earned wisdom.
Here's the reality from the front lines: As a practicing physician, I juggle 15-minute visits, endless EHR clicks, and anxious patients who Google faster than I can chart. New digital tools promise relief, yet most drop onto my desktop without my input—adding friction instead of removing it.
Every day, I experience firsthand how well-intentioned technologies can become obstacles rather than solutions.
This guide bridges the gap between tech builders and front-line clinicians. Use it to pressure-test assumptions and ship products the bedside will welcome, not resist.
2. Start with two questions every MD advisor will grill you on
Question 1: What exact problem are you solving, and for whom?
Describe it in one line: "<Specific person/team> loses <X hours or $> because <root cause>."
No jargon—just the human involved, the measurable loss, and the underlying cause.
Strong example: "Hospitalists spend 2.5 hours per shift on discharge documentation because current systems require duplicate data entry."
Weak example: "Our platform streamlines clinical workflows for better efficiency."
Founder Pitfall: Focusing on your solution before fully articulating the problem. A well-defined problem statement should make the solution almost self-evident.
Question 2: How well do you know your audience?
Suppose you want to build an AI agent to automate workflows for ER doctors. Take the time to get to know your audience—what tools are they currently using? What do they love and hate about the way things are now? What processes consume their time, leaving little room for what they truly love?
Prove you've walked the floor and heard the night-shift gripes firsthand. Only then can you design a solution that erases critical pain instead of superficial annoyance.
Before writing a line of code, create a "Day-in-the-life" map: Document every step in your target audience's workflow. Note not just the official process but the workarounds they've created. These workarounds are gold—they highlight where existing systems fail.
Remember: Each specialty (emergency, dermatology, pathology, radiology, rheumatology) is fundamentally different, with unique workflows, pain points, and decision constraints. It's like comparing a civil engineer to a structural engineer—sure we have some shared background and knowledge, but our questions, concerns, needs, and workflows are different. Build specifically.
There is no substitute for spending time with your intended customers. Cold-call, email, shadow—time on the floor beats time in Figma.
Common pitfalls we see:
Unclear definition of initial customers: "Providers" ≠ radiologists ≠ home-health nurses
Tech-first bias: "We have GPT-4o; let's find a use-case" rather than "Prior auth steals 6 hrs/week; let's kill the queue"
Understanding Clinical Contexts
Community vs. Academic Settings have radically different resource constraints, staffing, and incentives. Don't assume what works at Stanford will work in Scranton. The following structures should inform your design:
Private vs. public hospitals
New care delivery organizations (One Medical, Carbon Health) vs. traditional hospitals
Outpatient vs. inpatient settings
Available resources and staffing models
3. Build trust with your customers
Trust is the foundation of most transactions in healthcare. You pick a doctor because you trust them. In order to build trust, you must speak your user's language.
Front line clinicians tend to be wary of outsiders building in healthcare. Trust in healthcare is earned incrementally but lost instantly. Beyond speaking the language, demonstrate:
Clinical credibility through proper evidence validation—such as by doing pilot trials and publishing results
Technical reliability—such as by showing AI reasoning audit trails and by starting with low stakes use cases
Respect for clinical judgment by augmenting decision-making rather than replacing it
Finding clinical champions (nurses, physicians, etc.) who love your tool and will promote adoption amongst peers
Remember: A surprising amount of clinical work is emotional labor—navigating fear, trust, uncertainty. Tools that ignore this won't gain traction, no matter how smart the backend.
The Translation Guide: What Founders Say vs. What Clinicians Hear
Even with the best intentions, founders and clinicians often speak different languages. Understanding these translation gaps can prevent months of misalignment and failed adoption.
If you're pitching to clinicians, here's the translation guide you need:
FOUNDER SAYS: "Our AI reads all patient records in seconds!"
CLINICIAN HEARS: "Mystery black box that I'm supposed to trust blindly."
FOUNDER SAYS: "Completely seamless integration!"
CLINICIAN HEARS: "Another tab to open during my 12-minute patient visit."
FOUNDER SAYS: "Minimal training required!"
CLINICIAN HEARS: "Figure it out during your lunch break—we didn't budget for support."
FOUNDER SAYS: "Integrates with any EHR!"
CLINICIAN HEARS: "Basic API that breaks your actual workflow."
FOUNDER SAYS: "Saves hours on documentation!"
CLINICIAN HEARS: "You'll still review everything for liability anyway."
When presenting a new tool or product to clinicians, anticipate objections they might raise (such as liability, alert fatigue, loss of autonomy) and pre-empt them.
Clinical Pearl: Clinicians respond best to founders who acknowledge the limitations of their technology upfront. This builds more credibility than overpromising.
4. Navigating Healthcare's Triple Gatekeepers
Unlike consumer apps, healthcare technology must satisfy three distinct stakeholders:
Clinicians judge clinical utility and workflow integration
Administrators evaluate ROI and operational impact
IT/Security scrutinize compliance and technical integration
Each has veto power. Map your stakeholder landscape before pitching. Identify your champions and potential blockers at each level. One enthusiastic physician can't overcome administrative or IT resistance.
Important Note: The user is often not the buyer (especially for clinical tools), nor the decision-maker. The person forced to use your product may be three rungs down from the person who signed the contract. Design for that reality.
Founder Pitfall: Focusing exclusively on clinician buy-in while neglecting administrator and IT concerns. All three must say "yes" for your solution to succeed. Learn more about organizational types at different institutions of different sizes (hospitals, home health, managed care, private practices) to understand buy-in dynamics for your technology.
Stakeholder Mapping Exercise
Before your first pilot, answer these questions:
1. Who will use your product day-to-day?
2. Who will purchase your product?
3. Who will implement your product?
4. Who could block your product's adoption?
5. Who will champion your product internally?
Additional consideration: Department chairs and administrators are often not the strongest of the clinicians. Don't expect that their interest in a clinical solution necessarily means greater adoption by clinicians.
5. Differentiate Your Marketing Approach
Clinicians face constant interruptions and marketing fatigue.
Don't:
Schedule demos during clinical hours
Fill inboxes with generic outreach
Do:
Bring value first (lunch, useful resources, connections)
Respect their time with concise, evidence-based pitches
Remember: Everyone is busy in the clinic. Stand out by showing you truly care for your users. Lead with a give—bring lunch during their break instead of adding another Zoom call to their packed schedule.
6. Designing for Healthcare's Unique Constraints
Healthcare settings have constraints consumer apps don't:
Attention fragmentation: Clinicians are interrupted every 5 minutes
Cognitive load: Decision fatigue is real and dangerous
Legal liability: Who's responsible when something goes wrong?
Design principles should adapt: minimize clicks, enable one-handed operation, avoid unnecessary alerts, and create clear audit trails.
Decision-making happens in microseconds under stress. Tools need to be purpose-built. A tool that is too general for a high-stakes, immediate situation won't be used. A tool that is too prescriptive will also be ignored.
Founder Pitfall: Designing for ideal conditions rather than real-world clinical chaos. Test your product during the busiest hour of the busiest day. Remember that most clinicians already have a ton of different apps and interfaces that are disjointed—as clinicians, we just want more simplicity.
The 2 AM Test
There's a difference between "it works" and "I trust it when I'm exhausted and someone's crashing." Tools that succeed are battle-tested in the hardest hours. We talk about the 2 AM test when we choose residents. It's true for technologies too.
Understanding the Invisible Workflows
Many of the most valuable workflows are undocumented. We text colleagues, send clinical photos through text messages, screenshot from PACS, or use post-its to track high-risk patients. Tools that capture these invisible flows are the ones that truly help.
A lot of our time isn't just "doing medicine"—it's coordinating with social work, family, pharmacy, admin, transport, making calls and getting collateral information. Most tools ignore this ecosystem entirely, even though it's half the job.
7. When AI is (and isn't) the Hammer
AI promises to revolutionize healthcare, but it's not always the right tool:
AI works well for:
Pattern recognition in large datasets
Predictive modeling with clear variables
Reducing repetitive documentation tasks
AI still struggles with:
Novel or rare clinical scenarios
Highly contextual decision-making
Areas with limited or biased training data
Guardrails for Safe AI Use in Healthcare
If implementing AI solutions:
1. Always maintain human oversight for clinical decisions
2. Design for transparent reasoning, not black-box outputs
3. Implement robust feedback mechanisms for incorrect suggestions
4. Regularly audit for bias and performance drift
Critical Insight: If your tool saves time but increases liability, it won't be used. If it saves time but reduces diagnostic confidence, it won't be used. Time isn't the only currency.
8. The Reality of Clinical Decision-Making
Resource Constraints Shape Care
A tremendous amount of care is not delivered according to guidelines, but rather with regard to available resources. Clinicians are regularly forced to choose between multiple imperfect options to do what's best for their patients. For example, discharging patients we'd prefer to admit due to bed shortages, or choosing outpatient follow-ups over more thorough inpatient workups.
Integration Beyond Technology
Integration doesn't just mean with the EHR—it means fitting into clinical thinking. If I have to change how I think (or how my colleagues think) to use your tool, it probably won't last.
The Battle Against Tech Fatigue
We already experience tech fatigue. A tool that adds a new interface better be 10x better, not just "a bit" better. Otherwise, it'll be another tab I close.
Optimizing for Uncertainty
Don't just optimize for the happy path. Show me what happens when the data is wrong, incomplete, or weird. That's where most clinical tools break. I don't need new tools for things that are standard.
9. The Founder's Journey: Lessons from the Trenches
Start Narrow, Then Expand
The healthcare space is incredibly byzantine and fragmented, with different specialties and different organizations all having their own workflows. One of the hardest things for a founder to do is to create a solution that generalizes without becoming overcomplicated.
Key advice: Start with narrowing the problem down to the most specific instance possible and getting very few people to really love the product, then gradually expand into other use cases. Don't worry so much about trying to design a product top-down from day one that can serve all possible users in your market.
Process Mapping by Persona
It's a helpful exercise to list out potential users and use-cases. Do a mapping process on a persona-by-persona basis. The most difficult part of the early-stage is getting people to talk to you long enough to really understand their day, their pains, their current habits, etc.
Understanding the Clinical Day
If you had access to a panel of clinicians at the start of your journey, you would want all of them to describe their typical day: what time they start, what time they take lunch, how many patients they might see, what software they're already using, where they're spending their time.
A compilation of written user stories like this could go a really long way towards helping founders understand the clinical perspective. Even existing clinicians turned founders will inevitably have to do this sort of discovery to expand beyond their incredibly specific specialty/system/jurisdiction/role.
10. The Pilot Playbook
A well-designed pilot can accelerate adoption while a poorly designed one can kill momentum. Structure your pilots for success:
1. Define success metrics upfront (and get stakeholder agreement)
2. Start small (1-2 departments, 5-10 users)
3. Over-resource support during the pilot period
4. Gather both quantitative and qualitative feedback
5. Create a clear path from pilot to paid contract
Deeper discovery is always better. Before starting your pilot, conduct thorough quantitative and qualitative discovery:
Who is your buyer?
What is your budget?
What is your timeline?
What are you doing today to solve this problem? ("Nothing" is usually a bad sign—the problem isn't that painful)
What metrics are you measuring?
What specific measurable outcomes would make this project a success?
Founder Pitfall: Failing to convert successful pilots to contracts. Include the commercial conversation from the beginning rather than treating it as an afterthought.
11. Respecting the Art of Medicine
Healthcare is both science and art. Respect the nuance and art of medicine in what you build. Clinical expertise, intuition, and the human connection between provider and patient remain irreplaceable elements of care.
Your technology should enhance these human elements, not attempt to replace them.
Remember: Healthcare innovation isn't just about better technology—it's about better care. The most successful health-tech founders build solutions that clinicians can't imagine practicing without.
Use this playbook to bridge the gap between Silicon Valley speed and healthcare caution. The future of medicine depends on getting this right.