运营记录③｜277次提交与17种语言，还是停了 — 两个App走向停摆的过程

2026年5月底，相隔4天开始了两个移动App。一个是家人、情侣共享日常事务的App，另一个是经营水族馆的模拟游戏。都是个人开发，都上了应用商店。而现在，两个都停止了更新。

这一篇根据仓库记录排出两者走向停摆的过程。停法完全不同，所以作为对比放在一起。

两份履历

51天277次提交，平均每天5.4次，其中244次集中在6月。同期运转的信息网站是每天2.4次——只看动手的量，App一侧是两倍以上的速度。

停在过度打磨的那个

共享App在51天里做到了这些：三个标签页(共享清单、约定、垫付结算)、匿名登录、多群组归属与切换、推送通知、Web只读共享链接、订阅收费、邀请机制、按季节群发通知的脚本。版本号刻到了1.14.0。

然后是17种语言。从日语和英语开始，加上韩语、中文、德语、西班牙语、法语、意大利语、葡萄牙语，7月又一口气追加了印尼语、越南语、泰语、俄语、土耳其语、印地语、阿拉伯语。不只是UI的全部文案，推送通知的文面、商店介绍文，也都按语言数备齐了。

冷静地写下这项工作到底在干什么：**在没确认有多少人会用的情况下，把供给侧的面积扩大了17倍。**连在日语圈被用了多少都不知道的阶段，就在写阿拉伯语的推送文案。加翻译在技术上是舒服的工作——进度可数、提交可积。需求有没有增加，那里不显示。

仓库的路线图里，设计完成但未着手的项目原样挂着：加入审批制、按角色分权限。设计一直在增加，唯独”看看有没有人在用”这道工序，一次也没进来过。

7月21日的提交是对商店信息的细微修改。不是下定决心结束的，手就是停在了那里。

停在重写的那个

游戏那边，停法完全不同。

5月27日用Swift和SwiftUI开工，5月31日出现了一条”moved to flutter”的提交。**4天，就抛弃了此前的实现转向Flutter。**想同时上iOS和Android，判断本身说得通。只是这样一来，17天的运转里有4天用在了重写上。

之后到6月13日的两周里，做了多语言化、扭蛋调整、来场人数的平衡调整，到达版本1.2.0。40次提交做到能玩，算快的。

停下来，是因为不知道接下来该做什么了。没有准备了解玩家觉得什么好玩的手段，平衡调整好坏的判断标准就只剩自己的主观。最后一条提交是”将满员来场数重新调整为基准值的4.5倍”，而这个4.5对不对，从一开始就没有办法确认。

有些东西，一旦发布就改不了了

这个游戏里留着一处现在无法修复的地方。

iOS版的Bundle ID(标识App的字符串)有打错的地方，本该有的2个字母缺失了。Android侧的标识符拼写正确，于是同一个App在两个平台上标识符不一致。App Store发布后Bundle ID无法更改，所以这一处修不了。仓库的指南里也留着一句：“typo。已发布到App Store，不可更改”。

实际损害不大。但这一行对自己而言是象征性的：**因为急着发布，存在了以无法事后修正的形式被固定下来的判断。**提前发布有好处，但提前多少，也就有多少东西被就此定死。

还有一处：发布手册里写着”主要目标是Android，分发主轴是Google Play”。实际能上架的只有iOS，Play Console侧的准备清单大半行都停在未着手。写下的战略与执行的顺序错位了，停下来之后才发现。

两个App的共同点

停法不同，缺的工序却相同。两个都没有加入过确认需求的环节。

打磨的那个不停增加功能和语言；重写的那个换了地基一路跑到发布。两者都是供给侧的工作，都能用提交数来数。有没有人用，不会出现在提交数里。

看本站收录的个人开发案例，成长起来的案例无一例外，从最初期就有”外部反应会返回来的通道”：先发到Product Hunt和社区看反应再深入打磨的类型，或者一周赚了15万美元之后自己选择关停的Avatar AI那样，数字出来之后再选择撤退的类型。**能做出”关停”这个决断的，只有手里有数字的一方。**没有数字的一方，发生的不是决断，只是停摆。

一边上班一边做Python自动化副业、在累计15万日元的时点决定撤退的案例，金额虽小，但撤退的判断用上了数字，在这一点上，比这两个App走得更远。

关于没有公开的数字

下载量和付费金额，本文不公开。手头没有以可事后核验的形式保存。没有把它们保存成可数的形式，这件事本身就很能说明这两个App的性格。整理好了会在此补记。

能公开的只有提交数、日期和版本号。**做的一侧的努力被完整记录，被使用的一侧什么也没被记录。**这两个仓库就是这样的仓库。

本连载

• 第1篇 开始了4个，坏了3个
• 第2篇 两人开始的SaaS，坏在资本的分配上
• 第3篇(本文) 277次提交与17种语言，还是停了
• 第4篇 3个月月活9,103人 — 信息网站的实数