Hubble(hubble.ai)
- 官网
- hubble.ai
- PH
- www.producthunt.com/products/hubble-11/launches/hubble-11,2026-08-18,199 票(发布日 189)/ 日榜第 4、周榜第 25、月榜第 125 / 58 条评论
- 一句话
- 病人授权一次,Hubble 从 EHR、HIE、保险公司和传真/电话长尾里把病历捞回来,以一套结构化字段 + 可归档 PDF 通过一个 API 交付给下游 AI 产品。
- 团队
- 2 人,西雅图(南湖联合区)。CEO Prabha Dublish(前 Grow Therapy 首位产品/PM,Meta PM)、CTO Aaron Leon(前 Amazon One Medical 技术负责人,带 50+ 工程师做自研 EHR 与 AI)。YC S26,已融 $2.8M(YC、Basis Set、Madrona、Founders' Co-op、Treble、Zeno + 天使)YC 招聘页
- 收费
- 官网无定价页(
hubble.ai/pricing返回 404),只有「Book a Demo」和「Try the sandbox free」;第三方目录 SOTA2 也记「Pricing isn't published」〔www.sota2.com/products/hubble-hubble〕。YC 招聘页自述收入结构是「platform and usage fees」(平台费 + 用量费)。具体价格档抓不到,库里也没有。 - 状态判断
- 在涨(早期)——4 个月里从发布走到 5 个匿名案例、招 founding engineer、开西雅图办公室,但收入曲线无第三方可验。
- 证据强度
- 中。PH / YC / 官网 / LinkedIn 四方对得上;收入、客户数只有自报,indie、GitHub、HN、X 本地库全空。
发布之后的表现
收入
- indie(TrustMRR)按域名 hubble.ai 和名字 hubble 查:库里没有。这符合库的边界——TrustMRR 覆盖的是公开 Stripe 流水的独立开发者,B2B 医疗基础设施不在其中,「没有」不等于没收入。
- 唯一收入口径是自报:YC 行业目录里公司简介写「Four weeks in, we already have ten signed customers and 7-figure year-one revenue across platform and usage fees」〔自报,www.ycombinator.com/companies/industry/Healthcare%20IT〕。注意这是签约额/首年合同额,不是已实现流水,且发布四周时点(约 2026-09 中)的口径。
用户 / 下载
- appstore / googleplay / macappstore 里按名字命中的全是同名不同产品:Hubble Connected(摩托罗拉婴儿监视器,com.blinkhd 累计 220 万安装)、Hubble.Build(新加坡建筑 SaaS)、Hubble Connect。与本产品无关,不能当它的用户数。
- 官网自报「70,000+ providers reached」自报,指可触达的医疗机构数,不是客户数。
开发者关注
- github 库按 homepage=hubble.ai、owner=hubble-ai、描述含 hubble+medical 查:库里没有仓库。没有开源组件,也没有 star 曲线可看。
讨论
- hackernews 库按域名 hubble.ai 查:0 条故事、0 条 Show HN。一个 YC 医疗 API 在 HN 完全无声,说明它没走开发者社区路线。
- x 本地库(core 层约 560 人)按 hubble / hubblehealthai / medical record 查:0 条。创始人 Prabha 的发布推(2026-08-10)在 X 上存在〔x.com/prabhadublish/status/2086847112835367186〕,但不在我们采的圈子里。
- 公开报道:GeekWire 2026-09-25 报道其在 AI House Demo Day 宣讲「做病历界的 Plaid」〔www.geekwire.com/2026/seattles-answer-to-yc-demo-day-25-star…。
官网动态
- 站点活着且在更新:5 个匿名案例页(法务、保险核保、临床试验、护理交付、消费健康)、3 篇博客(患者访问权、TEFCA IAS、patient-mediated access,全是合规科普/SEO 内容)、security 页写「SOC 2 Type II in progress」、身份核验用 Persona 达 NIST IAL2。
- LinkedIn 公司页 1,525 关注,近 3 天/5 天/1 周都有更新(搬办公室、Uber 故事、四步流程)〔www.linkedin.com/company/hubble-ai-health〕。
- Wayback 对 hubble.ai 无存档快照,无法做站点前后对比。
自报 vs 实际
| 自报 | 出处 | 对照 |
|---|---|---|
| 10 个签约客户、首年 7 位数收入(发布 4 周) | YC 目录公司简介自报 | indie 库无记录;无第三方报道复述该数字;无法验证。7 位数首年合同额对 2 人团队 + $2.8M 种子是合理量级,但「签约」≠「到账」 |
| 70,000+ providers reached | 官网自报 | 无第三方可核;与「10 个客户」不矛盾(前者是覆盖网络,后者是买方) |
| 案例:单案成本降 95%、律师助理 15 小时→0、快 5 倍;核保 20–30 天→当天;首日拿到 75–80% 病历 | 官网案例页自报 | 客户全部匿名,无第三方引用,只能当营销材料 |
| PH 199 票 / 日榜第 4 | PH 库库 | 与 PH 官方 award 表一致(daily position 4),可信 |
为什么成了 / 没成
它没有「没成」,但也没到能证明 PMF 的阶段。成的部分很具体:选了一个别人不愿碰的脏活——病历长尾在传真机和没有 API 的小诊所里,纯 API 厂商(如 Flexpa、Health Gorilla 一类)到网络边界就停,Hubble 用浏览器/语音 agent 去打电话、登门户。这个「API 打底 + agent 补长尾」的组合是它真正的差异点,也是它敢说「其他 API 拿不到」的原因。加上创始人一个做过 Grow Therapy 的 AI agent、一个做过 One Medical 的 EHR,买方(诉讼、核保)听得懂他们在说什么。
风险同样具体:第一,合规地基是「患者个人访问权」(HIPAA 45 CFR 164.524),这条路径合法但脆弱——一旦某家医院把 agent 登门户判为滥用,覆盖率会掉;第二,收入是项目制/用量制的大客户单,10 个客户里丢 2 个就是 20% 波动,而 2 人团队要同时做交付、合规和销售;第三,SOC 2 Type II 还在进行中,企业采购会卡在这一步。
对想跟的人
别跟「病历 API」这个壳,跟它没覆盖的那一段:它自己承认价值在「API 返回空之后还继续找」,而这块的边际成本是人力——案例里写「15 个律师助理小时 → 0」,意味着它卖的是替代人力,客单价必须撑得住 agent 的调用与人工兜底。想切的话,位置在单一高价值场景的闭环(比如只做 PI 律所的案件级交付,而不是做通用 API),因为通用 API 会被 Flexpa 这类免费/低价连接层压价。最大的坑是合规叙事:一旦你把「患者授权」讲成产品卖点,就得承担每次授权被撤销、每个州对录音通话同意的差异——这不是工程问题,是运营问题,2 人团队很容易在这里被拖死。
没查到的
- indie(TrustMRR):无记录,拿不到 MRR、订阅数、是否挂牌出售。
- github:无仓库,无 star / fork / 提交数据。
- hackernews:0 条故事,无法看社区反应。
- x 本地库:0 条提及(创始人不在 core 名单,extended 层未查)。
- appstore / googleplay / macappstore:命中的全是同名不同产品,本产品无 App。
- 官网定价页:404,价格档、是否有免费额度、按次还是按案件计费均未知;Wayback 无存档,无法看定价历史。
- 客户名单、留存、实际到账收入:全部不可得,只有匿名的自报案例。
档案由 agent 建(deepseek/deepseek-v4.1-flash,43 步,2026-11-01T11:29);〔库〕= 我们自己的库,〔官网〕= 当天抓的网页。