The False Promise of Building “For Everyone” in Digital Health

What actually happens to a “for everyone” digital health startup once the press buzz fades and the first enterprise customer asks, “So who exactly is this for?”

You already know the slogan. “Accessible, equitable, scalable care for everyone.” It sounds noble. It plays well in pitch decks. It gets applause at conferences.

It also quietly kills companies.

Let’s walk through why “we’re building for everyone” is usually a red flag, what the data actually shows about who uses digital health, and how you, as a post‑residency founder (or soon-to-be) can avoid becoming another well-intentioned corpse in the venture graveyard.

---

The Myth: “If We Build For Everyone, We Maximize Impact”

The story founders tell:

1. Healthcare is broken.
2. Software scales.
3. Therefore, if we build a universal platform that works for all demographics, all payers, all conditions, we’ll reach the most people and do the most good.

That logic sounds airtight. Except for one detail: it doesn’t survive contact with reality.

Look at who actually uses digital health tools at scale. Not theoretically. In real usage data.

Typical Digital Health User Demographics (US)

Category	Value
Age 18-34	62
Age 35-54	54
Age 55+	29
Private Insurance	61
Medicare	37
[Medicaid](https://residencyadvisor.com/resources/medical-startups/why-good-clinical-outcomes-alone-wont-make-your-med-startup-succeed)	28
Income 100k+	68
Income <50k	26

These are typical ranges pulled from multiple surveys and claims-based analyses over the last few years (Pew, RAND, various health system reports). The details vary by study, but the pattern doesn’t:

• Younger, higher income, privately insured users dominate.
• Older, lower income, and Medicaid populations lag.
• Engagement drops hard as complexity of condition and social barriers increase.

So when a founder says, “We’re for everyone,” what they usually mean is, “We’re going to accidentally over-serve the most resourced 20–30% of the population while pretending we’re changing the whole system.”

That’s not evil. It’s just delusional.

---

The Real Users vs The Imaginary Users

You know who actually shows up to digital products. You’ve seen it in clinic.

The “imaginary user” in decks:

• Works hourly or multiple jobs
• Has 2–3 chronic conditions
• Juggles childcare, transportation, and unstable housing
• Has patchy internet or shares a single smartphone in the household
• Navigates Medicaid, prior auths, and fragmented care

The actual early adopters of digital health:

• Stable housing, stable employment
• Reasonable health literacy
• High smartphone penetration, good data plans
• More agency in choosing providers and products

When you build “for everyone,” you’re trying to design:

• One interface that works for a 28‑year‑old software engineer with anxiety
  and
• A 67‑year‑old with CHF, CKD, and limited English proficiency.

Those are not “users.” Those are different universes. They have different:

• Device access
• Trust levels
• Time constraints
• Cultural expectations
• Cognitive load
• Financial incentives

Trying to serve both with one generic “for everyone” product is like designing a single vehicle that’s simultaneously a city scooter, an ICU ventilator, and a school bus. You end up with something that does everything poorly and nothing well.

---

The Data: “For Everyone” = Weak Signal, Weak Outcomes

I’ve sat in payer and health system meetings where teams evaluate digital health vendors. The pattern is boringly consistent.

The vendors that try to be universal usually show:

• Modest engagement (e.g., 15–25% of targeted population actually using it)
• Minimal sustained behavior change
• No clear impact on the costliest, sickest cohorts
• And when you slice the data by risk or SDOH, the value gets even weaker

Compare that to companies that go narrow.

CareBridge didn’t say, “We’re going to transform care for everyone.” They locked onto high-need, high-cost populations on Medicaid long-term services and supports (LTSS). Ugly space. Unsexy. But focused.

Cityblock? Started with Medicaid and dually eligible patients. Not “everyone.” Very decisively “the people the system usually ignores.”

Meanwhile, you’ve seen plenty of flashier products die, even with nice UIs and big checks. Why?

Because health systems and payers are not actually asking, “Who helps everyone a bit?”

They are asking:

• Who moves the needle on my HCC risk?
• Who keeps my CHF patients out of the ED?
• Who helps me hit this specific quality measure?
• Who reduces readmissions in this particular cohort?

Generic “we help everyone feel better” does not survive that conversation.

---

Why “For Everyone” Is So Seductive (Especially For Clinicians)

If you’ve just finished residency or are burned out on the job market nonsense, your instinct is to fix the whole system. You’ve watched:

• Homeless patients discharged with 6 meds and no phone.
• Privately insured patients getting concierge-level attention.
• Working parents missing “urgent” follow-ups because of their jobs.

So you start a company with the righteous idea: “No more of this. We’ll make something that finally works for everyone.”

Here’s the uncomfortable part: that moral instinct collides with harsh market math.

Let me lay it out.

Dimension	"For Everyone" Product	Focused Product
User definition	Vague, broad	Sharp, narrow
Sales messaging	Fuzzy, feel-good	Concrete, outcomes-based
Implementation	Complex, many variants	Simpler, repeatable
Data & outcomes	Weak signal, mixed	Strong signal, specific
Reimbursement fit	Hard to anchor	Easy to map to codes/ROI

You cannot ethically ignore vulnerable populations. But trying to design one system that works equally well for all of them is how you guarantee you help nobody meaningfully.

You want to do real good? Pick a group and go deep.

---

The Physics of Focus: Why Narrow Beats “Universal”

There are some basic “physics” of digital health that people like to pretend don’t exist.

1. Clinical complexity and operational complexity scale together

Serving:

• Healthy-ish commercial lives with a wellness app? Low clinical complexity, lower ops.
• Dialysis patients on Medicaid across multiple states? High clinical and regulatory sludge, huge ops burden.

When you say you’re “for everyone,” you implicitly agree to handle the full spectrum. That’s not noble. That’s suicidal.

2. Behavior change isn’t generic

A medication reminder:

• For a tech worker with ADHD is one problem.
• For a patient choosing between meds and food is a different problem.
• For a patient mistrustful of the system after prior discrimination is yet another.

The intervention levers differ. Incentives differ. Communication styles differ. Product design differs. You can’t generic your way through that.

3. Sales and contracting hate vagueness

I’ve listened to these conversations:

Founder: “We improve engagement across your whole population.”
Payer: “Which line of business?”
Founder: “All of them.”
Payer: “We’re not buying a philosophy. Show me something that moves a metric I get fired over.”

The companies that win say things like:

• “We reduce all-cause 30-day readmissions for CHF in your Medicare Advantage lives.”
• “We close care gaps for diabetic Medicaid patients to improve HEDIS and Stars.”
• “We prevent ED visits for moderate persistent asthma in commercially insured kids.”

Everyone else is just noise.

---

The Equity Trap: Pretending Universal = Fair

Here’s where it gets spicy.

A lot of “for everyone” rhetoric is dressed up as equity. That sounds nice. It is also often lazy.

“Building for everyone” tends to do three harmful things:

1. Centers the already-privileged user
   Your design committees, advisory panels, and usability tests disproportionately capture the people who have time, devices, and comfort with tech. Then you slap diverse stock photos on the website and declare victory.

2. Under-invests in the hardest problems
   If you’re truly building for a Medicaid patient with unstable housing, you’re not just writing more push notifications. You’re doing care coordination, benefits navigation, language access, community partnerships. That’s heavy. That’s expensive. That doesn’t look good in a 24-month hockey-stick revenue graph. So it gets watered down.

3. Hides failures in averages
   Your average engagement looks okay. But look at subgroup data and it falls apart. Vulnerable groups drop out. People with SDOH risks engage less. The product “works” mostly for the people who already had options.

This is how well-meaning founders build digital health that quietly widens disparities while tweeting about inclusion.

If you care about equity, stop saying “everyone.” Say: “We’re building for X, and we’ve designed for their actual constraints. Here’s our data.”

---

A Better Frame: “Who Are We Willing Not To Serve (Yet)?”

The adult question in digital health isn’t “Who do we serve?”
It’s “Who are we willing not to serve in version 1 and 2 so we can actually help someone in the real world?”

You do not have infinite runway. You do not have infinite engineering, design, or clinical capacity. You definitely do not have infinite attention from your customers.

You need a wedge.

Focusing Your Digital Health Product

Step	Description
Step 1	Big Vision
Step 2	Define Use Case
Step 3	Define Use Case
Step 4	Define Use Case
Step 5	Measure Outcomes
Step 6	Iterate or Expand
Step 7	Specific Population

That wedge might be:

• A specific condition (e.g., CHF, severe mental illness, gestational diabetes)
• A specific line of business (e.g., Medicaid MCO, MA plans, self-insured employers)
• A specific episode (e.g., perioperative, post-discharge, postpartum)
• A specific workflow (e.g., prior auth for high-cost drugs, remote titration of HF meds)

You get a wedge, prove real value, then expand. Not the other way around.

---

Where “For Everyone” Actually Makes Sense (Rarely)

There are narrow categories where broad applicability is viable:

1. Infrastructure, not interventions
   Think claims rails, EHR plumbing, interoperability layers, identity verification. These are horizontal tools that support other apps. They’re not patient-facing behavior change engines.

2. Regulatory or compliance utilities
   E-prescribing, e-labs, e-signature, specific reporting utilities. Every provider has to do them. Standardization wins.

3. Simple, universal workflows
   Appointment reminders. Basic intake forms. Telehealth scheduling. Even then, the winners tend to specialize by segment or use case (payers vs health systems vs clinics).

If you’re building anything that even smells like care delivery, condition management, or engagement: “for everyone” is almost always a red flag.

---

Concrete Steps: How To Stop Lying To Yourself About “Everyone”

Let’s make this tactical. You’re a post-resident or early attending thinking about a startup. What should you actually do?

1. Brutally define your first 10,000 users

Not “patients with chronic disease.” That’s lazy.

You want something like:
“Adults 45–80 with CHF on Medicare Advantage, living within 30 miles of a partnered health system, with ≥1 hospitalization in the last year.”

You should be able to look at a specific patient in your old clinic and say, “Her, yes.” “Him, no.”

2. Align the business model to that real user

Look at the messy part: who pays, and why.

Common Digital Health Business Models by Segment

Category	Value
Employers	3
Commercial Payers	4
Medicare Advantage	5
Medicaid MCOs	2
Health Systems	4

(Think of the values as how often digital health companies meaningfully win in each segment on a 1–5 roughness scale. Medicaid is hard for a reason.)

You cannot build “for everyone” and then say, “We’ll just see who pays us later.” Payers fund solutions to tightly defined problems in tightly defined populations.

3. Design for reality, not your own life

If you trained at a big AMC and use an iPhone 15 and Oura ring, your intuition is poisoned for certain segments.

Talk to:

• Patients who miss visits regularly
• People who’ve never logged into a portal
• Front-desk staff
• Home health nurses
• Community health workers

Then build for one of those realities. Not all of them.

4. Decide explicitly who you’ll fail for initially

Write it down:

• “Our product will not work well for patients without smartphones.”
• “Our product is not initially designed for people with serious cognitive impairment.”
• “Our V1 is focused on English and Spanish only.”

Harsh? Yes. Honest? Also yes.

The alternative is pretending you’re inclusive while building something functionally exclusive. That’s worse.

---

What Actually Scales: Specific Wins, Then Broader Systems

Look at the few digital health companies that actually got somewhere. Not the ones with gushing TechCrunch articles. The ones with revenue and repeatable outcomes.

They didn’t start with:

“We’ll be the operating system for all healthcare for all people.”

They started with something like:

“We will reduce unnecessary ED visits for XYZ group by 20%.”

They stacked wins. One use case. One population. One line of business. Then another.

Typical Focused Expansion Path

Category	Value
Year 1	1
Year 2	2
Year 3	4
Year 4	7

One focused use case in year 1. Two aligned use cases in year 2. Then more. That’s how you earn the right to talk about “systems change.”

Not by declaring from day one that you’re for everyone.

---

The uncomfortable truth

If you’re serious about impact, you have to let go of the fantasy that your first product will serve all patients, all providers, all payers, and all conditions. That story is built for TED talks, not for contracts.

Real change in healthcare looks smaller, messier, and more specific than that.

You don’t have to save everyone on day one. You have to save someone, measurably, and prove it. Then you earn the right to expand who that “someone” is.

Years from now, you won’t remember the slogans you used in your first pitch deck. You’ll remember the moment you stopped trying to build for everyone and finally chose who you were willing to fight for first.

---

FAQ

1. Isn’t focusing on one population just cherry-picking the easiest patients?

It depends who you choose. If you pick “healthy commercial lives who just want nicer wellness tracking,” yes, you’re cherry-picking. But narrowing your focus doesn’t mean picking the easiest; it means picking the most coherent. High-need, complex groups (e.g., dual-eligibles, SMI, ESRD) are actually better targets if you design specifically for them and align your contracts to cost and outcome improvements. Specific ≠ easy. Specific = tractable.

2. How do I talk about a big vision to investors without saying “for everyone”?

You separate vision from wedge. You say: “Long term, we see this infrastructure supporting multiple populations and payers. But our entry point is X, because they have Y problem, and we can move Z metric in 12–18 months.” Investors who understand healthcare don’t want vague universality; they want a credible path from a sharp wedge to a larger market. Vision without a wedge is fantasy. A wedge without vision is a feature. You need both—but you lead with the wedge.

3. What if regulators or partners push me to be more universal (e.g., ‘We need solutions that work for all our members’)?

You call the bluff with data. “We’d love to support more of your members over time. Our current product is optimized for A and B. In that group, we can commit to achieving X. If we pretend we can do this for all your members today, everyone will be disappointed—including you.” Sophisticated partners respect constraints. The ones who demand “for everyone” from day one usually also churn vendors every 18 months when promises don’t match outcomes. You do not want to be in that churn cycle.