一款App磨了5年,下一次10个月出了30款。月流水$22,000背后的应用量产转向

※ 正文中出现的美元金额,均附上按1美元=150日元计算的大致日元换算。

“一款App磨5年”与”10个月出30款”。这是同一位开发者、凭同样的技能做出的两种结果。拥有8年iOS工程师职业经历的Max Artemov,曾把第一款App(一款卡路里计算App)打磨了5年多,却始终未见起色。2025年2月他改变方针,从单一项目转向组合式(portfolio)运营。截至2025年12月10日刊登的Indie Hackers采访时,这30余款App组成的矩阵合计MRR已达$22,000(月流水约330万日元)。

这个案例想要验证的,不是”多做几款就能撞上一个”这种粗糙的教训,而是制作顺序本身的颠倒,为什么能撬动数字。

已公开的数字

需要指出的是,“单款平均$730”只是把合计金额除以款数得出的数字,实际分布并未公开。既然本人提到”初速过后消失的App占大多数”,可以自然推断收入集中在头部少数几款,但具体细分并未公开。

在做什么

制作的是一批Flutter打造的小型App。每一款App塞进去的功能,是解决特定用户痛点的”单一核心功能”。后端用Firebase解决,变现不靠订阅而靠广告。付费设计、付费转化路径优化、价格测试这些繁重工作,从一开始就被排除在外。

支持体系也没有全部由本人一手扛下。用户反馈和评论处理交给发行方(publisher)负责,只有真正的故障问题会传到本人这里。要一个人运营30款App,前提是把运营的固定成本压下来的设计。

局势转变的瞬间

转折点很明确。2025年2月,他看了Adam Lyttle的一个YouTube视频,主张不应该专注于单一项目,而应该组建多款App的组合矩阵。他本人的形容是:“这彻底改变了我对移动App的理解。”

前后落差极端。转变之前,一款App投入5年多,成果为零;转变之后,10个月推出30余款,合计MRR达到$22,000。投入的技能和人数都没有变,变的只是时间的分配方式。

还有一个数字发生跃迁的节点,是掌握了ASO之后。他明确表示,学习之后”展示量、下载量、收入都提高了50%“,这是在量产这个框架内,对每一发子弹命中率的进一步提升。转折点是”转向量产”,放大器则是”ASO”,呈现出两级结构。

拆解为何奏效

表面上看是”出得多所以撞上了”。但实际起作用的机制要具体得多。

第一,制作顺序的颠倒。以往是”做想做的App→事后再考虑获客”。转变后变成”先在App Store内找到热度超20、难度低于60的关键词→围绕这个关键词设计App→用在标题、副标题、描述文案中”。先确认需求存在再动手,结构上就不容易再发生把5年时间浪费在零需求领域的事故。搜索关键词,是人们已经在寻找的地方的地图。

第二,把App Store的初速流量当作免费的验证装置来使用。上线后的最初几天,App Store会给新品一定程度的曝光。多数App在那之后跌到每周10〜50次下载并逐渐消失。他把这里当作及格线来处理——不需要维持峰值,只要不骤跌、能稳定在某个水平就算有希望。这不是用某个固定下载数机械切割,而是逐款观察流量高峰过后的走势来判断。也就是说,在付广告费之前,先用平台自带的免费曝光来测量需求是否存在。

第三,在设计层面剔除了情感上的执念。“用户怎么看那款App,可以留到我做下一款App的时候再说。""做出来发布出去,让它根据真实用户的反应自己浮沉。“只有一款App的开发者,放弃这款App就意味着事业的终结,所以撤退的判断容易变形。有30款,一款的失败不过是统计上的一个数据点。可以说,当年5年的固着,不是技术力不足造成的,而是因为只有一个选项这种结构造成的。

第四,放弃了过度设计。以前会在SOLID原则或理想的架构上花时间,现在则只保留”核心功能所需的东西”。他的建议也很直白:“不要害怕发布。不要因为想打磨或者再加一个杀手级功能而浪费时间。做出一个没有bug、只带一个功能的版本,发布出去。”

尚未成功的部分与承担的风险

首先要说明前提:这个案例失败期反而更长。8年职业生涯中,超过5年投入到一款没有出结果的App上。他选择了一个饱和品类——卡路里计算,不断堆砌功能,在架构上精雕细琢。量产战略是这种反思的反面,并非从一开始就被选中的正确答案。

现在的模式也有弱点。收入来源集中在广告上,获客也几乎全面依赖App Store的算法。一旦ASO的运作前提发生变化,30款App会同时受到冲击。他本人也意识到这一风险,提到2026年计划开发几款SaaS以分散收入来源。可以理解为他的自我评价是:组合矩阵的分散度,应该按”依赖对象的种类”而非”App的款数”来衡量。

此外,大多数App的运营前提是无法越过初速流量这道坎的。30款这个数字,与其说是成功的证明,不如说更接近于把低存活率纳入考量后所需的必要数量。

能复制到什么程度

容易复制的是判断规则部分:在关键词热度、难度上设定门槛来决定是否着手;根据发布后的表现决定继续还是放弃;功能只做一个就发布。这些都不需要特殊资产。ASO工具也是普遍可以获取的。

另一方面,也有一些条件无法直接照搬。8年iOS开发经验,让他每款App的开发成本远低于旁人。对Flutter跨平台开发和Firebase组合的熟练程度也是前提。把支持和评论处理都能交给发行方的体系,也不是谁都能马上准备好的。如果开发速度只有一半,同样10个月能出的就是15款,考虑到收入分布集中在头部几款这一点,结果很可能并不成比例。

而且,这种方法与打造”深入人心的那一款”的战略并不合拍。为了多出几款而削减功能、靠广告回收成本的设计,难以移植到高单价产品或依赖长期客户关系的业务上。量产不是目的,而是廉价探测需求所在之处的一种手段，这样理解,应该更接近这个案例的实际含义。

相关阅读

• 独自做到月$100K的Photo AI,Pieter Levels的打造方式
• 24本Kindle书籍积累起来的个人出版收入结构