Overview
Hey Healthcare was a billing service for private practices, combining professional medical billers with software. YC lists the Summer 2019 company as inactive. Its company profile described insurance verification and claims management, rather than clinical care or an appointment marketplace. [1] [2]
Andrew Coyle's retrospective attributes the ending to limited continued growth and an increasingly service-based business. The useful lesson is about the boundary between software and the work customers still need to complete. Better billing screens can help people coordinate; they cannot supply missing enrollment or payer decisions. [3]
Image 1 / 1
Founding Story
Coyle's launch announcement named Evelyn Gillie as his co-founder and described making health insurance more transparent. He had left Google to start the company. YC's current profile identifies Coyle as a former Flexport designer and Hey Healthcare co-founder. These records establish the people and the initial administrative focus. [4] [1]
The benefit checker expanded into billing support with professional billers. [3]
Timeline
- 2018–2022: Coyle labels this period his co-founder and product-designer role. [3]
- 2019: YC lists the founding year and Summer batch. The role period does not establish an earlier legal founding date. [1]
- During operations: The service expanded beyond benefit checking. [3]
- Later: Coyle reports dissolution and returned capital; the retrospective gives no exact closing date. [3]
What They Built
The company invited practices to upload insurance claims for its technology and professional billers to handle. Its published specialties included medical billing, insurance verification and claims management. That was a combined operating service and software product. [2]
The founder shows billing dashboards and messaging, using dummy data. The screens do not establish verified collections. [3]
Market Position
Private-practice administration crosses several systems and organizations. The provider supplies information, a billing team handles work, and payers impose transaction-specific requirements. The fact that a task appears in one application does not mean that application controls the entire process.
Current alternatives already address coordination. DrChrono's RCM task page includes claims assigned to practices for information or coding clarification. Claim.MD exposes separate payer-enrollment states for professional claims, electronic remittance advice and eligibility. Its documentation also distinguishes credentialing from enrollment. These capabilities weaken a proposal to build another broad billing dashboard without a specific unmet job. [5] [6]
Business Model
The public offering was full-service medical billing. The observed company material does not publish a fee schedule, collection percentage, revenue, margins or service labor per account. A current product prototype should therefore avoid treating the service as proven recurring software revenue. [2]
YC backing establishes the accelerator relationship. It does not disclose total funding, cash consumed or the amount later returned. Those figures remain unavailable. [1]
Traction
Customer counts and retention are unavailable in the observed account. We cannot establish whether higher fees or lower service effort would have changed the outcome. [3]
Post-Mortem
Coyle called the “biggest obstacle” “streamlining client operations,” citing enrollment exceptions. He chose to “dissolve the business and return capital to investors” as growth slowed and services expanded. His account does not audit every cost or decision. [3]
The product problem is a handoff with an external dependency. A biller can identify missing practice work, but a practice must complete it and a payer may still need to confirm it. A team can finish its assigned action while the overall enrollment remains pending. Collapsing those states would hide the next task rather than resolve it.
Current DrChrono services similarly assign enrollment information and payer-specific forms to the customer. That documented responsibility boundary supports testing a focused exception handoff. It does not establish demand for a new vendor or a guaranteed improvement in reimbursement. [7]
Key Lessons
- Separate software from service effort. Measure the manual work needed per practice alongside subscription or billing-service revenue.
- Give external dependencies an owner. A pending practice action and a pending payer decision need different next steps.
- Keep transaction states distinct. Eligibility, remittance and claim enrollment do different jobs. Evidence for one does not automatically establish another.
- Test coordination against existing tools. Current billing products already expose tasks and enrollment. A new workflow must demonstrate a useful difference.