夜雨聆风这件事最反直觉的地方，不是创始人多会写代码，而是他几乎没有靠投广告获客。
这款 App 叫 Mumigo，用来追踪公交和火车，覆盖 160 多个城市。从 2017 年上线到现在，它累计下载量超过 520 万次，月活用户约 40 万，App Store 评分数量约 7.5 万。
创始人 John Makavoy 来自苏格兰，最早是平面设计师，不是传统意义上的程序员。他自学编程，一个人把这个 App 做了出来。
这个案例真正值得拆的，是一条很清晰的独立 App 增长路径：
先解决一个用户会主动搜索的问题；再用 App Store Optimization 拿到免费、精准、可持续的搜索流量；然后在用户感受到价值的瞬间请求评分，把排名继续推高；最后用订阅和 A/B 测试，把下载量变成收入。
很多独立开发者总想着怎么发短视频、怎么投广告、怎么做社媒传播。但 Mumigo 的增长提醒你：如果你的产品解决的是一个明确问题，用户本来就会去搜索它。
关键不是制造需求，而是站到搜索需求已经发生的位置。
需求不是想出来的，是在雨里等出来的
John 最早在苏格兰爱丁堡的一家公交公司工作。
那时 Uber 刚流行起来。用户打开手机，就能在地图上看到出租车一点点朝自己驶来。这种体验很新鲜，也很直观。
John 想：为什么等公交不能这样？
他每天早上想喝完咖啡再出门，而不是提前站到公交站，在雨里等 10 分钟、20 分钟。他想要一个工具，能让自己看到公交车现在在哪里，什么时候到站。
这就是 Mumigo 的起点。
它不是从市场报告里来的，也不是从“哪个赛道最热”里来的，而是来自一个他自己每天都会遇到的问题。
John 的观点很朴素：如果你是开发者，最好的点子往往是你自己遇到的问题。如果这个问题对你有用，很可能也会对很多其他人有用。
这句话听起来简单，但很多产品失败，正是因为创始人一开始就脱离了真实场景。
他们先想“我能做什么技术”，再想“怎么找用户”。John 刚好反过来：先有一个具体生活场景，再为了这个场景学习技术。
这里有一个判断标准：这个问题会不会让用户主动打开 App Store 搜索？
等公交就是这种问题。用户不需要被教育，也不需要被种草。他站在公交站、火车站、地铁站，焦虑已经发生了。他只需要一个能立刻解决问题的工具。
先用设计能力启动，再补技术能力
John 一开始并不会开发智能手机 App。
他的第一步，是先用 Illustrator 做设计图。
这很符合他的设计师背景。先把界面、体验和产品样子画出来，再一点点啃开发部分。
早期版本是用 Xamarin 做的。Xamarin 是一个跨平台移动开发框架，可以用 C# 和 .NET 构建 iOS、Android 应用。这是 John 当时比较熟悉的技术。
但做网站和做移动 App 很不一样。
移动 App 要处理地图、定位、滑动面板、不同系统的交互习惯，还要考虑网络、性能、权限等问题。John 说，那段时间就是不断构建、失败、调整。
上线后，他也发现早期代码很乱，于是开始重构。
后来，Swift 已经成熟，Flutter 也刚发布。John 用几个月时间，把 iOS 端重写成原生 Swift。因为 Mumigo 大量使用地图和滑动面板，Flutter 对这类界面也很合适，所以他又用 Flutter 快速重建了相关部分。
从今天看，很多步骤也许可以借助 AI 工具更快完成。但 John 的经历说明了一件事：早期技术不一定要完美。
对独立开发者来说，更重要的是先把一个真实场景跑通。
用户愿意下载、愿意打开、愿意在关键时刻使用，技术债才值得慢慢还。反过来，如果需求不成立，再漂亮的架构也只是提前装修一间没人来的店。
增长的第一层：让 App 出现在用户搜索结果里
Mumigo 能做到 500 多万下载，靠的不是大规模广告，而是 App Store Optimization。
ASO 是 App Store Optimization，应用商店优化。它的核心是研究用户会在应用商店里搜索什么词，然后把这些词合理放进 App 的标题、副标题、关键词列表和本地化内容里，让用户搜索时更容易看到你的 App。
对 Mumigo 这种工具类 App 来说，ASO 不是锦上添花，而是主要获客渠道。
因为用户的需求通常很明确。
他们不是在信息流里随便刷到一个公交 App，然后突然决定下载。他们是已经遇到问题，于是去 App Store 搜索“纽约地铁”“芝加哥火车”“公交追踪”这类具体词。
这类搜索词背后不是泛兴趣，而是高意图。
John 把 ASO 拆成了三个步骤。
第一步，找到位置相关关键词。
比如 New York subway、Chicago train。不同城市的人，对同一种交通工具的叫法可能完全不同。
纽约用户会搜 MTA subway，芝加哥用户可能会搜 CTA L train。
如果你只用一个通用词，很可能错过大量精准需求。
John 把这些关键词放进 App 标题、元数据和关键词字段里，让 App 开始出现在相关搜索结果中。
同时，他还更新了截图。
不同地区看到的截图要更本地化。比如纽约用户看到的，不应该是一张泛泛的地图，而应该是一眼看上去就和纽约交通相关的画面。
这会让用户产生一个很直接的判断：这个 App 确实适合我所在的城市。
这不是装饰问题，而是转化问题。用户搜索的是具体城市，截图也必须回答具体城市。
第二层：把每个城市、每种叫法都变成入口
John 还发现了一个有意思的细节：其他语言和地区的本地化，也可能影响美国 App Store 的搜索索引。
比如，在墨西哥西班牙语本地化里加入关键词，这些关键词也可能被美国 App Store 索引，并且获得类似权重。
这对 ASO 来说很重要。
因为 App Store 给每个地区、每种语言的标题和关键词空间有限。通过本地化，你相当于获得了更多可被索引的关键词空间。
当然，这不是让你胡乱堆词。关键词仍然要和产品相关，也要服务用户理解。
John 的做法，本质是把每个城市、每种说法、每个搜索习惯都当成一个入口。
一个公交追踪 App 听起来是单一产品，但用户搜索它的方式可能有几百种。
这就是工具型产品做搜索增长最容易被低估的地方。
你以为自己只有一个产品，其实你有几百个入口。每个入口单独看都不大，但加起来就是一条很长的免费流量河。
不花钱找关键词：直接看 App Store 搜索建议
ASO 的第二步，是不断发现更多有效关键词。
John 提到有两种方法。
一种是用 Apple Search Ads 测试。你可以投少量广告，观察哪些关键词带来的点击和转化更好。
另一种完全免费：直接用 App Store 搜索框。
你输入某个词的前几个字母，App Store 会自动弹出搜索建议。大多数用户搜索时，往往会点击第一个或第二个建议词。
所以这些建议词本身就很有价值。
John 会围绕自己的 App 功能，输入各种交通相关词，观察系统提示哪些词，再判断哪些关键词值得加入。
这种方法看起来很笨，但很有效。
因为越具体的关键词，竞争往往越小。比如“train app”这种词可能很难抢，但某个城市的某种交通叫法，可能搜索量没那么大，却非常精准。
只要你把这些长尾词放进标题、副标题、关键词字段和本地化内容里，就有机会在小搜索量、高意图的词上冲进前五。
对一个独立开发者来说，这比砸钱买泛流量现实得多。
第三层：评分不是面子工程，而是排名燃料
ASO 的第三步，是在 App 内请求评分。
John 说，如果一个 App 想冲到关键词第一名，就需要持续收到评分。
但什么时候要评分很关键。
不能在用户刚打开 App、还没得到价值时就弹窗。那样只会打扰人。
你要找到 golden moments，也就是用户刚刚感受到产品价值的黄金时刻。
对 Mumigo 来说，这个时刻可能是用户点击某个车站，看到了公交或火车正在地图上实时移动。
那一刻，用户会意识到：这个 App 真帮我解决了问题。
在这个时候请求评分，用户给好评的概率会高很多。
所以评分不是运营后台里的虚荣数字，而是搜索排名的燃料。
评分越稳定，搜索排名越容易上升；排名越高，下载越多；下载越多，又会带来更多评分。
这就是 ASO 的复利。
第四层：把下载量变成订阅收入
Mumigo 前几年下载量不断增长，John 最早主要靠横幅广告变现。
当时每月广告收入大约 8000 美元。
但疫情来了，出行需求骤降，广告收入突然消失。
John 很快意识到，必须转型。
当时订阅模式在移动 App 里越来越普遍。他决定围绕订阅重新设计产品，加入一些让用户愿意按年付费的高级功能。
2020 年 8 月，新版本发布。
接下来一年，订阅收入一点点增长，最终替代了原本消失的广告收入。
这一步很关键。
广告模式的问题是，你的收入高度依赖流量和广告市场。当外部环境变化时，你很难控制。
订阅模式则更接近产品价值本身：用户愿意持续付费，说明这个工具对他有长期价值。
也就是说，Mumigo 的生意从“把用户注意力卖给广告主”，变成了“让用户为持续解决问题付费”。
真正把收入拉上去的，不是新功能，而是 A/B 测试
2021 年，Mumigo 迎来了真正的收入增长。
原因不是又做了一个新功能，而是 John 开始认真做 A/B 测试。
A/B 测试指同时测试两个或多个版本，比较哪个版本带来的转化率更高。比如不同的付费墙文案、价格组合、按钮位置、试用方式，都可以测试。
John 针对 onboarding 和 paywall 做了大约 10 次实验。
Onboarding 是用户首次打开产品时的引导流程。Paywall 是付费墙，也就是用户看到订阅价格和权益的页面。
结果非常明显：转化率从 0.5% 提升到了 8%。
这直接把收入从每月 8000 美元左右，推到了超过 3 万美元。
这个变化特别值得注意。
很多人以为增长只能靠更多流量。但 John 的案例说明，如果你已经有稳定下载量，优化转化率可能比获取新用户更有杠杆。
同样 1000 个新用户，0.5% 转化和 8% 转化，是完全不同的生意。
这也是这篇案例里最值得独立开发者记住的一点：当流量已经稳定，继续加功能未必是最高杠杆动作。更该做的是找出用户在哪一步流失，然后用实验把那一步改掉。
好的引导流程，要顺着用户当下的处境
John 展示了 Mumigo 的首次启动流程。
它的设计目标很明确：快速展示价值。
因为很多用户下载这个 App 时，可能正站在公交站或火车站。他们没有耐心看 20 页 onboarding。
所以第一步，是快速请求定位权限。对公交追踪 App 来说，这是最关键权限。
接着，App 用几个简短页面告诉用户能获得什么：不只是公交追踪，还有额外功能。
这些页面其实也在为后面的付费墙做铺垫。
然后出现付费墙。
它提供三个选项：年度计划带 7 天免费试用、低承诺的周计划，以及给不喜欢订阅的人准备的终身计划。
最有意思的是，如果用户点击关闭，App 不会立刻放弃，而是开启 reverse trial。
Reverse trial 可以理解为反向试用：用户不需要先绑定信用卡，也不需要承诺付费，就能获得一段时间的 Pro 功能体验。Mumigo 会提示用户“免费享受一周 Pro”。
这降低了体验门槛。
用户先用到高级功能，看到价值之后，再决定是否付费。
这个设计的核心不是“多给福利”，而是把付费决策放到用户体验价值之后。先让他看到车真的在地图上移动，再让他判断 Pro 功能值不值得买。
Mumigo 的魔法时刻：地图上真实移动的车
进入 App 后，用户可以看到周围的交通站点。
点击一个公交站，再点击某个出发班次，就能看到公交车在地图上实时移动。
这就是 Mumigo 的核心魔法时刻。
用户不用猜车什么时候来，也不用一直站在雨里等。他能看到车在哪里。
此外，Mumigo 还有 Trip Assist 功能。
开启后，服务器端的机器学习系统会持续关注用户旅程前方发生的情况。如果某班车延误，或者用户可能错过换乘，系统会发送通知，并提供替代路线。
这就是从“查信息”升级到“辅助出行”。
一个好产品往往不是堆功能，而是抓住最核心的焦虑：我会不会错过车？我是不是该现在出门？如果延误了怎么办？
Mumigo 的高级功能，正是围绕这些真实问题展开。
技术栈：老而稳定，比新而炫更重要
John 现在的技术选择很务实。
后端用 Laravel 和 PHP。他形容自己的选择是“old and boring”，也就是老而稳定。
营销素材和 App 图形界面，主要用 Adobe Creative Suite。动画会用 Lottie，他会在 After Effects 里做动画，再转成 Lottie 放进 App。
ASO 研究用 Appfigures。订阅管理用 RevenueCat。事件分析用 Mixpanel。Cloudflare 用来做地理负载均衡，每月大约 90 美元。
他也会用 ChatGPT 处理很多事情，每月大约 20 美元。
运营成本方面，最大开销是服务器。他运行大约 20 台专用服务器，每月约 2500 美元。地图等第三方 API 每月约 1000 美元。
对一个月入 3 万美元的单人 App 来说，这个成本结构相当健康。
这里也有一个启发：技术栈不必追求潮流。对长期运营的工具型产品来说，稳定、便宜、可维护，往往比“最新框架”更重要。
给移动 App 创业者的两个提醒
采访最后，John 给想在 2025 年做移动 App 的人两个建议。
第一，解决你自己的问题。
因为做产品会遇到很多墙。尤其是晚上和周末做副业时，你会反复受挫。
如果这个问题本来就是你自己的痛点，你会更有动力坚持下去，也更容易判断产品该怎么做。
第二，不要只盯虚荣指标。
John 早期也很关注月活用户这些数字。但后来他发现，这些指标不一定真正推动收入。
真正让业务增长的，是事件分析。
事件分析指追踪用户在产品里的具体行为，比如完成 onboarding、看到付费墙、点击试用、开启某个功能、完成订阅等。
只有知道用户在哪一步流失，你才能通过 A/B 测试改进。
Mumigo 的收入增长，正是来自这种数据驱动的优化。
这个案例真正能学的，不是做公交 App
John 的故事不是“人人都应该做公交 App”。
真正值得学的，是判断一个独立 App 有没有机会时，可以先问四个问题：
第一，这是不是一个用户已经有痛感、并且会主动搜索的问题？
第二，这个问题有没有足够多的长尾关键词，比如城市、场景、语言、叫法、平台习惯？
第三，用户第一次使用时，有没有一个足够明确的魔法时刻，让他愿意留下评分？
第四，当下载量稳定后，能不能通过 onboarding、paywall、价格和试用方式，把使用转成订阅？
如果这四个问题都有答案，产品就不是只靠灵感活着。
它有一条可被反复优化的增长路径：
从自己的问题出发，做一个真实有用的工具。
先用自己已有能力启动，比如设计、原型、简单代码。
把产品上线，再用真实用户反馈重构和改进。
通过 ASO 找到免费、精准、可持续的搜索流量。
在用户感受到价值的瞬间请求评分，推动排名继续上升。
当广告模式受外部冲击时，转向更稳定的订阅模式。
最后，用事件分析和 A/B 测试优化转化率，把下载量变成收入。
很多人低估了应用商店搜索。
他们总觉得增长只能靠短视频、社交媒体、广告投放。但如果你的产品解决的是一个用户会主动搜索的问题，ASO 可能就是最便宜、最持久的渠道。
John 一个人做到 520 万下载，不是靠运气，而是靠长期研究用户怎么搜索、怎么决策、什么时候愿意付费。
这不是一个更励志的故事，而是一个更朴素的事实：独立 App 的增长，可以从搜索框开始。
案例分享翻译整理自油管频道StarterStory。
本公众号会持续更新AI和互联网创业相关的内容，如果你觉得有用，请点赞关注，下期见。
