Runify的成功故事揭示了一个小众跑步App如何在26天内实现六位数收购的秘诀。从精准对标Liftoff的竞技模式，到用5美元预购验证市场需求，再到Instagram内容矩阵的暴力分发策略，这个案例完美演绎了如何用‘验证先行，开发跟进’的敏捷打法突破冷启动困境。更值得关注的是其App Store预购机制对社交类产品冷启动的颠覆性解法。

今天分享一个很适合小团队看的案例：Runify，https://www.runifyapp.com/

主角叫Caleb Dean，他做了一个叫Runify的跑步 App，产品上线后，只跑了 26 天的收入，就被买家以六位数价格收购。

今天的分享除了产品本身，更想通过这个案例，详细拆解一个消费 App 如何从想法、验证、分发、上线、冷启动、用户反馈到出售的全过程。

01 不是先做产品，是先找一个已经赚钱的参照物

Runify 的想法并不是凭空冒出来的。

Caleb 最早做过一个非常小众的 App，叫UriBrave，解决的是“害羞膀胱”的问题。

这个 App 太小众了。简单说，就是有些人在公共厕所、旁边有人、有人排队或可能被别人听见的时候，会因为紧张而无法小便。这个 App 核心是提供了一套应对上述问题的训练方式。

这个需求非常窄，但用户一旦真的有这个困扰，搜索意图和付费意愿都很强，转化率也很高。

这个经历给了Caleb一个很重要的经验：小众需求可以赚钱，但如果市场太小，后面也很难做大。

后来他开始重新找方向。

他给自己定了一个选题标准：要进入一个已经被验证过的市场。

具体来说，他希望看到这个方向里，至少有 1-3 个 App 已经能做到每月 10 万美元以上收入。

他的逻辑是：如果一个品类里已经有产品跑到不错的收入，说明需求、付费和分发方式都被验证过。

小团队要做的，是找到一个相邻场景，用类似的机制和模式切进去。

Runify 的参照物是 Liftoff。

Liftoff 是一个游戏化健身 App，核心是把健身动作做成排名和等级系统。

用户可以记录自己的训练，然后通过排名、段位、朋友之间的比较，获得持续训练的动力。

Caleb 看到这个产品后，就想到一个很直接的迁移：

如果健身房训练可以做成排名系统，跑步为什么不可以？

跑步天然有数据,距离、配速、时间、GPS 轨迹、手表记录，都比健身房训练更容易验证。

健身房里，用户可以随便填一个卧推重量，但跑步数据来自手表、运动手环或手机 GPS，更适合做排行榜和竞技系统。

所以 Runify 的定位很简单：一个有排名、有段位、有朋友竞争的跑步 App。

很多人做产品，一开始就想做一个“全新的东西”。

但 Caleb 的方式更加现实：先找已经有人愿意付钱的模式，然后换一个用户群和场景。

他不是从“我想做什么”出发，而是从“市场已经证明了什么”出发。

02 真正的验证，是让用户先付 5 美元

有了想法之后，Caleb 却没有立刻花几个月去做完整的产品。

他先做了一个很简单的验证。

他研究了 Liftoff 的 Instagram，发现对方有一类内容很有效：用一张等级图，把不同训练成绩对应到不同段位。

比如某个重量、某个动作、某个水平，分别属于普通、优秀、高手还是精英。

Caleb 直接把这个内容格式迁移到了跑步。

他做了一批类似的短视频：不同跑步项目，对应不同成绩和等级。比如 100 米、200 米、5 公里、10 公里，跑到什么时间算什么水平。

因为都是早期素材，所以没有找到更高清的图片。但可以看到，Runify 和Liftoff 的内容和模式几乎一模一样。

这些图标和素材，很多是用 ChatGPT 生成的。视频本身也不复杂，一条内容大概 30 分钟就能做出来，然后用排程工具自动发布。

他一周发了不到 50 条视频。

这些视频不是单纯为了涨粉，而是被导向一个很简单的落地页。落地页也是用 ChatGPT 写出来的 HTML 页面，核心内容只有几句话：

• Runify 是一个跑步排名 App，你可以和朋友竞争，提升段位，解锁奖励；
• 你可以留下邮箱加入候补名单，也可以付 5 美元，成为早期用户。

这个 App 当时还不存在。

但结果是，两周左右，Runify 拿到了 2000 多个候补用户，还有 90 多个人真的付了 5 美元。

这个数字本身不大，但验证意义很强。

因为留下邮箱和真正付钱，是两种完全不同的信号。

用户愿意留邮箱，只能说明他感兴趣；用户愿意为一个还没做出来的 App 付 5 美元，说明他已经愿意承担一点成本。

这也是 Caleb 判断这个事儿“可以做”的关键依据。

Runify 的验证方式很粗糙，但有效。

它不追求完美的产品说明页，也没有完整功能介绍，只是用短视频内容把用户吸引过来，再用一个小额付款按钮测试真实意愿。

这一步跑通后，Caleb 才开始认真做产品。

03 分发不能等产品做完再开始

Runify 最值得分享的地方，是 Caleb没有把“开发”和“增长”分开。

很多团队的节奏是：先做产品，产品做完，再开始营销。

Runify 的节奏是：

想法刚开始验证，内容就已经在跑；产品开发期间，分发也没有停过。

Runify 的主要流量来自 Instagram，少量来自 TikTok。

Caleb 发现，Instagram 对高频发布的惩罚没有那么明显，所以他们一度每天发 9 条 Reels/信息流。

TikTok 的表现则不一样，一旦发布频率变高，流量会被明显压低，所以他们最后把重心放在 Instagram。

这背后有一个很具体的执行方法，就是他们不是每天从零想内容，而是找到一个可复制的固定格式，然后只改变量。

格式是固定的：

一张跑步成绩等级图；一个具体跑步项目；

一组不同水平对应的成绩；一个有点口语化、有情绪的标题或描述。

变量也很清楚：

项目可以换，100 米、200 米、5 公里、10 公里都可以；

成绩可以换，不同等级对应不同时间；

标题可以换，比如更偏挑战、更偏朋友比较、更偏自我测试；

文案可以换，换成不同的语气和网梗。

后来，Runify 的 CTO 还做了一个内部工具，可以在一分钟内生成 1 万个类似视频变体。

也就是说，AI 和自动化在这里的作用，不是替代创意，而是放大一个已经被验证的内容格式。

Caleb 先通过手工内容找到可行格式，再用 AI 工具把它批量化。

这样做的好处是，团队不用每天赌一个全新的创意，只需要不断测试变量。

他们第一个月靠这类内容拿到了大约 500 万播放。这也是 Runify 能跑起来的核心原因之一。

产品还没上线，用户已经通过内容知道它；

产品还没完整做完，团队已经知道哪些跑步项目更容易传播；

上线之前，候补名单、早鸟付费用户、Instagram 粉丝都已经积累了起来。

这对今天做 AI App 的团队很有参考价值。

现在开发一个 App 的门槛确实低了，很多原型几天就能做出来。但开发速度变快之后，真正稀缺的东西变成了分发。

一个产品做出来没人知道，开发再快也没有意义。

Runify 的做法是反过来的：

先用内容证明有人会被这个概念吸引，再把产品做出来。

04 产品设计也没有从零发明

Runify 的产品开发并不轻松。

一开始，Caleb 找过两个开发者合作了两三周，效果不理想。后来，他找到了第三个开发者，这个人后来成为 Runify 的 CTO。

CTO 接手之后，连续一个半月每天高强度开发，把产品赶出来。

Caleb 自己主要负责产品设计和决策。

他花了三天时间，每天大约 15 小时，在 Figma 里把整个 App 的界面和流程画出来。

他的原则是：尽量让开发者不用猜。

每个按钮点下去是什么，每个页面怎么跳转，用户从注册到看排行榜再到记录跑步，大概怎么走，他都会提前画清楚。

Runify 的早期设计大量参考 Liftoff。

但不是简单照抄，因为 Liftoff 做的是健身房训练，Runify 做的是跑步，两者场景不同。

但在等级、段位、竞争感、排行榜这些体验上，Liftoff 已经验证过很多东西，Runify 没必要从零发明。

Caleb 还看了其他表现不错的 App 的新用户引导流程，比如一些健康、健身、生活方式类产品。

Runify 第一个版本上线后，很快发现新用户引导的转化率不够高。

因为原来的表达更偏“这是一个好玩的跑步排名 App”。

后来他们改成更明确的结果导向：

这个排名系统可以帮你成为更好的跑者，因为它给你目标、比较和持续动力。

这个修改看起来很小，但方向很关键。

因为用户不是为了看一个漂亮排行榜才下载 App，用户真正想要的是变强、跑得更快、超过朋友、保持训练动力。

所以 Runify 后来把产品表达从“有趣的排名”调整成“帮你进步的竞争系统”。

这也是早期产品最重要的工作：不断把功能翻译成用户真正关心的结果。

05 早期付费用户，是最好的测试团队

Runify 在正式上线前，有一批很特殊的用户：那 90 多个付过 5 美元的人。

Caleb 没有把他们只当成付款记录。

他逐个联系这些早期用户，感谢他们支持，留下自己的邮箱，还邀请他们关注 Runify 的 Instagram。

后来，这批人变成了 Runify 最重要的早期反馈来源。

他和其中大约 20 个用户建立了更直接的联系，有些甚至加到了 WhatsApp。测试版本出来后，他会把测试链接发给他们，让他们帮忙试用、反馈问题、报告 Bug。

这比普通调研更有价值。因为这些人已经付过钱，他们不是随便说说，而是真的期待产品上线。

他们愿意花时间反馈，说明对这个产品有更强需求。

Runify 还利用 Instagram 做快速调研。比如他们会问用户：

你更希望在 App 里直接记录跑步，还是用手表记录，还是连接到运动社交 App，比如Strava？

用户用佳明手表、Apple Watch、Strava的比例如何？

用户更在意排行榜，还是更在意自己的等级变化？

这些反馈直接影响了产品决策。

跑步 App 有一个很关键的问题：到底要不要自己做记录？

如果 Runify 自己做 GPS 记录，它就会更像一个完整跑步工具，也会更接近和运动社交 AppStrava 竞争；

如果它只接 Strava，它就变成 Strava 上面的一层游戏化体验；

如果它接佳明、Apple Watch、Strava，又要处理更多集成和技术复杂度。

最后他们发现，用户使用的工具非常分散，有人用佳明，有人用 Apple Watch，有人用 Strava。

于是 Runify 决定都做，这也让产品复杂度提高了不少。

Runify 不是一个简单套壳 App。它有首页信息流、排行榜、等级逻辑，还要连接佳明、Strava、Apple Watch 等数据源。

跑步本身涉及 GPS、距离、配速、活动记录等数据，也不是两周就能随便拼出来的东西。

这也是后面买方愿意出价的原因之一。

它不是只有一个漂亮界面和订阅弹窗，而是已经做了一些别人接手后可以继续放大的底层结构。

06 App Store 预购，解决了社交产品最难的第一天

Runify 还有一个非常值得单独讲的动作：App Store 预购。

这个动作对普通工具类 App 可能没那么关键，但对 Runify 很重要。

因为 Runify 有排行榜和社交属性，这样的产品最怕上线第一天没人。

用户打开 App，看到排行榜是空的，朋友也没有，等级系统没人参与，第一感觉就会很差。

尤其是排行榜产品，热闹本身就是体验的一部分。

Caleb 的做法是，先把一个非常基础的版本提交给 Apple 审核。

那个版本很简单，只有两个标签页，没有完整的新用户引导，只是为了先通过审核，获得在 App Store 上架预购的资格。

通过之后，Runify 就可以开放预购。

用户在 App Store 上预购后，等正式发布当天，App 会自动下载到他们的手机上，同时用户会收到 Apple 的通知。

Runify 的预购大概开放了两周，拿到了 3000 个预购下载。

这意味着，正式上线那一刻，Runify 不需要一个个等用户看到邮件、点击链接、再去下载。

大量用户会在同一天被推到产品里。

上线后不到一小时，Runify 的排行榜就很快被填满，甚至达到他们设置的上限。

这一步解决的是社交产品非常关键的冷启动问题。

如果 3000 个用户分散在一周里陆续进入，每个人看到的产品可能都很冷清。

如果 3000 个用户在同一天集中进入，产品会立刻显得活跃。

很多团队做候补名单，但候补名单有天然损耗。邮件可能进垃圾箱，用户可能不打开，打开后也不一定下载。

Runify 自己也遇到过这个问题：他们给候补用户发邮件时，有相当一部分进了垃圾箱，打开率也有限。

App Store 预购的优势是，它把“预约兴趣”更直接地转成“上线当天的实际下载”。

对需要人气、排行榜、社交关系、内容池的产品来说，这个动作很有启发。

这里要注意，在我们国内，不一定有完全一样的 App Store 预购红利，但思路可以迁移：

上线前要想办法把用户集中到同一个时间点进入产品，而不是零散地流失在漫长等待里。

07 上线当天，他们几乎把所有渠道都用上了

Runify 的正式上线不是单点动作，而是一组动作同时发生。他们做了几件事：

在 Instagram 上用 Story 持续预热；

在 Reddit 上发帖；

Caleb 在自己的 X 账号发产品演示视频；

给候补名单用户发上线邮件；

逐个私信早期付费用户，提醒他们注册并领取权益；

通过 App Store 预购，让 3000 个用户在上线当天自动下载。

早期付费用户还有一个特殊安排。

他们之前花 5 美元买的是 early adopter 权益，相当于早期支持者。

Runify 上线后，需要确保这些用户成功注册，并把他们的账号改成终身订阅权益。

这带来了一些客服工作，但也让 Caleb 和核心用户保持了更紧密的联系。

上线当天的收入，很多来自候补名单和早期支持者收到的折扣码。

候补名单、早鸟付款、Instagram 粉丝、App Store 预购、个人账号曝光，都在上线当天汇到一起，变成真实下载和收入。

也就是说，Runify 不是上线之后才开始找用户。

它是在上线前，已经把第一批用户放在不同“池子”里：

Instagram 关注者、候补名单用户、5 美元早期付费用户、App Store 预购用户、以及X 上关注 Caleb 进展的人。

上线当天，只是把这些池子一起打开。

08 收购机会来自 X 上一个陌生人发来的私信

Runify 的收购机会，来自一条很普通的私信。

Caleb 当时在 X 上持续发 Runify 的进展。他的账号并不大，发产品演示时可能只有几百个关注者。

但他经常表达自己对 Runify 的信心，比如觉得它有机会做到每月 10 万美元收入。

后来，一个叫 Dev Sh 的人给他发私信，问他是否考虑出售 Runify。

Caleb 一开始并不热情。

因为很多这种私信都只是泛泛询问，不一定真的有购买意图。他还反问对方，是不是只是复制粘贴消息，把公司名换成 Runify。

对方确认确实对 Runify 感兴趣后，双方才开始交流运营数据。

当时 Runify 的情况大概是：

上线不到一个月，收入还没有完整月度数据；

已有两三千下载，且每天还有几十到一百个下载；

有一些试用用户即将转化；

用户平均会打开 App 多次；

社交和排行榜机制已经跑起来。

估值最难的地方是，收入数据太短。双方只能根据 26 天收入和即将转化的 7 天试用用户，估算月经常性收入。

最后估出来大约是 3000 美元 MRR，再按大约 5 倍 ARR 估值。

对一个上线不到一个月的 App 来说，这个倍数不低了。

但买方看中的不只是当下收入，Runify 有几个特点：

它已经证明内容分发能跑通；

早期用户有付费意愿；

产品有社交和数据集成，不是特别容易复制；

创始人已经把一套获客方式跑出来；

买方本身也有 App Studio，有开发、分发和资金团队；

买方团队里还有很多跑步爱好者，和产品场景匹配。

同时，对 Caleb 来说，出售也不是简单退出。

交易结构里，他保留了 Runify 30% 的权益，还有 6 个月的额外收益安排和一笔现金奖励。

买方接手后，会带来开发资源、分发团队和资本，可以继续投达人、用户生成内容、付费投放等增长方式。

所以这笔交易对他来说，不只是把 App 卖掉。

它更像是把一个早期项目交给更有资源的人继续放大，同时自己拿到现金、保留上行空间，也获得了下一次创业的启动资金和个人品牌曝光。

他后来说，自己原本很看好 Runify，也觉得它可能做到每月 10 万美元收入。

但一个上线不到一个月的 App，仍然有大量执行风险。拿到一笔不错的现金，同时保留 30% 权益，对他来说是一个降低风险的选择。

09 这不是暴富故事，而是一套速度很快的验证流程

Runify 这个案例，真正值得分享的是这整个流程。

第一步，选题不是凭感觉，而是找已经赚钱的参照物。

Liftoff 验证了“健身+排名+游戏化”的需求，Runify 把它迁移到跑步。

第二步，验证不是问用户喜不喜欢，而是让用户做动作。

2000 个候补用户说明有人感兴趣，90 多个 5 美元早鸟付款说明有人愿意掏钱。

第三步，内容不是宣传品，而是验证工具。

同一套内容格式不断换变量，既带来流量，也帮助团队判断什么跑步项目、什么成绩、什么文案更容易引发用户反应。

第四步，开发和分发同时推进。

产品还在开发，Instagram、候补名单、早鸟用户、预购下载都已经开始积累。

第五步，冷启动要提前设计。

Runify 用 App Store 预购，让 3000 个用户在上线当天集中进入，解决排行榜产品第一天没人气的问题。

第六步，早期用户不是“用户量”，而是产品共创者。

愿意付 5 美元的人，后来变成测试者、反馈者、Bug 报告者，也帮助团队做出关键产品决策。

第七步，出售的核心不是收入，而是信号。

买方买下的，是一个已经证明有需求、有分发、有用户热度、有一定产品壁垒的早期资产。

最后，这套流程对国内初创小团队也很有参考价值。

国内不一定有完全一样的 Instagram Reels、App Store 预购和 X 推广环境，但底层逻辑是相通的：

• 做消费 App，先别急着憋一个大而全的产品；
• 先找一个已经被验证的需求；
• 再找到一个可以低成本测试的内容格式；
• 用短视频、社群、小红书、抖音、视频号、公众号、微信群，先把需求跑一遍；
• 能留联系方式是一层验证，愿意付小额定金，是更强验证；
• 愿意参与内测、反馈问题、帮你传播，是更深验证。

以上，祝你今天开心。