乐于分享
好东西不私藏

30 个小 App 凭什么打赢 1 个大 App:独立开发者「该做几个产品」的组合计算器

30 个小 App 凭什么打赢 1 个大 App:独立开发者「该做几个产品」的组合计算器

一句话版:十年前「选一个产品、死磕一个赛道」是对的,因为做一个带支付的 SaaS 要 约 400 小时;到 2026 年同样的东西 约 25 小时(含登录、支付、UI)就能上线。单次尝试成本掉了一个数量级,「集中赌一个」就过时了 —— 该改成 多下注跑组合。作者给了一个能直接算的公式:年尝试数 A =(每周小时×50)/(单产品小时 H + 情感止损税 K);年期望成功数 P = A × 成功率 S × 分销倍数 D。按 P 落在哪个区间决定做 1 个还是 5 个还是 30 个产品。配套是一条铁打的 止损规则(kill rule):到期限没打到信号就归档。

为什么值得读

市面上讲「一人多 App」的文章大多是案例复盘 —— 谁做了 5 个、谁做了 30 个、月入多少。看完热血,但回到自己身上还是不知道:我到底该做几个产品?

这篇不是案例,是 一个决策框架 + 一个能套数字的计算器。它把「做单品还是做组合」从信仰之争,变成一道你拿自己的每周工时、单产品开发时长、有没有分销渠道就能算出来的题。算出来 P<1 就老老实实做单品,P≥3 就放开做组合。它还把「什么时候该砍掉一个失败产品」写成了带阈值的合约 —— 这才是组合打法真正难的地方:不是开得多,而是 杀得快

三个数字,十年里全变了

作者的论点立在三个变化上(数字为作者论断,非统计来源):

维度
2014
2020
2026
做一个带支付的 SaaS
约 400 小时
约 120 小时
约 25 小时
(含登录、支付、UI)
拿到一个有效信号
1 次尝试,跑 6–12 个月
10–30 次尝试
,各跑 30–90 天
单次尝试成功率
约 1/8 ~ 1/15
,保守取 1/10

结论很直白:十年前你 一年只能开一枪,现在 一年能开二十枪。按 1/10 成功率算,二十枪一年大约能跑出 两个付费产品。当尝试成本塌方,「把所有筹码压一个山头、誓死守住」就不再是默认最优解 —— 作者的原话是:一个人,很多产品,很多小注,没有哪座山头金贵到值得陪葬。

收入是幂律的,别被平均数骗

有人会拿「一人跑 30 个 App、月入 $22K」来论证组合,但 平均到每个 App 只有 $733,这个数字是误导。真实形态是幂律 —— 钱高度集中在头部一两个产品(以下为作者估算,非公开实测):

排位
占总收入
对应金额(总 $22K)
第 1 个 App
35–50%
$7,700–$11,000
第 2 个
15–20%
$3,300–$4,400
第 3 个
10–15%
$2,200–$3,300
第 4–6 个
各 5–8%
各 $1,100–$1,760
第 7–15 个
各 1–3%
各 $220–$660
第 16 个及以后
趋近于零

这恰恰是组合打法的逻辑,而不是反例:你 事先不知道哪个会是那个头部产品,所以只能多开几个去撞;一旦某个跑出信号,就把时间和钱压上去。30 个里大部分是陪跑甚至归档对象 —— 它们的作用是 帮你找到那 1–3 个,不是各自都要赚钱。

计算器:把「做几个产品」算出来

这是全文最硬的部分。先定义输入:

变量
含义
取值示例
H
做出一个可用版本的小时数(含登录、支付、UI)
25
S
单次尝试成功率
默认 0.10
D
分销倍数
冷启动 1.0;有自有渠道 3.0;5K+ 活跃粉丝名单 8.0
W
每周可投入小时数
20
K
情感止损税:每个失败产品额外耗掉的小时(舍不得砍而拖的时间)

三个计算:

年尝试数        A = (W × 50) / (H + K)
年期望成功数    P = A × S × D
每个成功的成本  C = (H + K) / (S × D)

按 P 落在哪个区间,决策直接给出:

期望成功数 P
该怎么做
P < 1
做 单品 —— 你一年连一个成功都跑不出,分散只会全军覆没
1 ≤ P < 3
做 5 个的小组合,但要 严格止损
P ≥ 3
做 激进组合,砍得更快

两个算例:

  • 每周 20 小时、25 小时一个产品、无分销、无止损税:A = 40,P = 4,C = 250 → 激进组合。
  • 同一个人,但养了一个 1 万粉的 X 账号(D=8):A = 40,P = 32 —— 此时瓶颈不再是「能跑出几个成功」,而是 一个人能维护几个产品。P 要按你的精力上限截断。(这里的 X 账号只是「分销倍数 D」的一个例子 —— 换成邮件名单、小红书、微信社群等任何 自有渠道 同理,重点是有没有一个能反复触达的分发口子。)

换句话说:分销渠道是乘数。同样的开发能力,有没有一个能一键触达的受众,决定你是该做 4 个还是该做几十个。

止损规则:组合打法真正的护城河

作者反复强调:跑组合能成的人,都是止损规则最狠的那批。 没有止损,组合就退化成「30 个半死不活的项目同时拖垮你」。止损规则是三件套,缺一不可:

组件
内容
① 时间期限
SaaS 30 天;内容类产品 60 天;平台/市场类 90 天
② 信号门槛(达标即留)3 个付费用户
,或 $50 MRR,或 100 活跃用户且留存粘性 >20%
③ 止损动作(没达标就执行)
归档代码仓库 / 关停域名 / 退掉剩余订阅用户 / 写一份复盘

关键在于:这是一份事先签好、用来压制未来那个心软的自己的合约。到了第 30 天没打到信号,不许「再给它一个月」,直接执行止损动作。写复盘那一步尤其重要 —— 它把一次失败转成了下一次的判断力。

每周节奏:节奏本身就是护城河

组合打法不是同时猛干所有产品,而是固定的每周循环:

时间
做什么
周一
分流(triage):扫一遍组合的动向、回支持消息、看每个产品的一项核心指标
周二–周四
开发:要么上一个新产品,要么改进头部三个产品之一,要么按合约执行止损
周五
分销:发出本周做了什么、经营自有渠道、回复互动 —— 不写新代码
周六
休息
周日
一小时指标复盘,更新看板,定下周重点

作者的话:节奏才是护城河。 单个产品都能被抄,但一个人能稳定地「每周出一点、分销一点、砍掉该砍的」这套运转,是抄不走的。

什么时候单品仍然胜出

组合不是道德高地,也不是万能解。有三种情况,老老实实做一个大产品反而对:

情形
为什么单品更优
构建成本高、有护城河
开发基础设施、数据库、语言运行时、深度 ML、硬件等 —— 第一个客户之前就要 约 600 小时;这类东西天然挡住后来者,值得集中投入
盘子大但反馈慢
企业级 / 强监管 / 政府类,销售周期长达 6 个月 —— 你根本没法靠「30 天止损」快速试错
要打品牌
你想成为「那个东西的创始人」(下一个 Stripe / Linear / Figma) —— 投资人和媒体只认 一个故事,组合反而稀释叙事

作者也很诚实地交代了组合打法的天花板:它最差的结局是 品牌上沦为「做各种小玩意的人」。它适合的目标是 自由和现金流,不是做一家定义品类的公司。一句概括:组合能让你辞掉那份工作;单品如果成了,能把你带到 IPO。

独立开发者可复用的最小步骤

  1. 先算一遍你的 P:把每周工时 W、单产品工时 H、成功率 S(默认 0.10)、分销倍数 D 代进 P = (W×50)/(H+K) × S × D,看落在哪个区间。
  2. P<1 别硬开组合:工时不够就先做单品,或先把 H 压下来(用模板/脚手架),或先把 D 抬上去(养渠道)。
  3. 把 D 当乘数来经营:一个能一键触达的受众(邮件名单 / 粉丝)比多做一个产品更能放大整盘期望值。
  4. 下注前先写止损合约:期限 + 信号门槛 + 止损动作,三件套白纸黑字定死,且 必须包含「写复盘」
  5. 固定每周节奏:分流 / 开发 / 分销分开排,别让某个产品天天偷走你全部注意力。
  6. 遇到高护城河、慢反馈、要打品牌三种情形,主动切回单品 —— 别教条地什么都跑组合。

把这套跑顺的核心不是「开得多」,而是 敢按合约杀掉没信号的产品。作者结尾那句值得记:你这辈子最划算的一年,是砍掉三个烂点子、而不是死守一个好点子的那一年。

译者按:把这套框架映射到 iOS / Android

原文的计算器是平台无关的,但移动端有两个变量得专门校准,否则照搬会踩坑。

① App Store 审核会拉长反馈环,30 天止损要放宽

原文给 SaaS 定的止损期限是 30 天 —— 那是 Web 产品「今天 push、明天就有数据」的节奏。移动端不是:iOS 首次审核可能就吃掉几天到一两周,过审后还要等 App Store 自然曝光 + 自然搜索把第一批真实用户喂进来。把 30 天硬套到 iOS,你很可能在产品还没拿到第一个完整曝光周期时就把它砍了。

更稳的移动端口径:止损期限从「上架那天」算起,放宽到 「首个完整审核 + 曝光周期」结束(经验上 iOS 约 45–60 天起);信号门槛(3 个付费 / $50 MRR)不变,变的只是给信号兑现的时间窗。Android 审核快、可分阶段发布,反馈环比 iOS 短,可以更接近原文的 30 天。

② 单次尝试成本:移动端怎么把 25 小时再压低

原文的 H=25 小时是 Web SaaS 口径。移动端能不能也压到这个量级,取决于你有没有用对脚手架:

环节
把 H 压下来的做法
订阅 / 支付
用 RevenueCat 接管 StoreKit / Google Play Billing,省掉收据校验、跨平台订阅状态这一大坨
App 骨架
用成熟模板 / AI 生成脚手架(如 Rork 这类)起 onboarding + paywall + 设置页,别每个新 App 重写一遍
商店页素材
沉淀一套可复用的截图模板和 ASO 关键词流程,新产品换皮即用

把这几样固定下来,一个移动 App 的「可上线版本」H 确实能往 25–40 小时靠 —— 这正是组合打法在移动端成立的前提。反过来,如果你每个 App 都从零手搓支付和 onboarding,H 居高不下,算出来的 P 会很低,那就老实做单品。

另外提醒一句:本文是 决策框架,不是案例。如果你想看一个真人按组合思路跑出来的样子(5 个 App、ASO + 付费投放找分发、失败就放掉),可以去看本号此前那篇 22 岁学生做 5 个 App 的复盘 —— 两篇正好一框架一实操。

改写自 GDS K S《The Portfolio Math: When 30 Small Apps Beat 1 Big One》(dev.to)。本文把原文的尝试成本测算、组合计算器(A/P/C 公式与决策阈值)、三件套止损规则、每周节奏与单品例外编译为中文,并补充 iOS/Android 审核周期与单次尝试成本压缩的译者按;原文中的成功率、$22K、头部占比等数字为作者论断与估算,非统计数据。