BibleChat 如何借助 Adapty 扩展至 1500 万用户

BibleChat 是一款基于信仰的 AI 应用，提供个性化经文对话、每日经文和圣经学习资源。该应用由罗马尼亚创业者 Laurențiu Bălașa 和 Marius Iordache 创立，于 2023 年 5 月上线后实现爆发式增长，一年内用户达到 1500 万，并登顶美国 App Store 参考工具类别榜首。

团队规模不大。第一年，Marius 是唯一的工程师，独自负责 iOS、后端等所有工作。现在团队有了 iOS 和 Android 开发者，但仍然是一个小而快速的团队。这种速度的增长很快就暴露出基础设施的挑战。他们需要一个能与他们同步扩展、技术可靠且响应迅速的订阅合作伙伴。

BibleChat 上线之初使用 RevenueCat 进行基本的订阅处理，负责收据和交易管理。随着应用规模扩大，Marius（负责工程）在其基础上构建了自定义展示位置逻辑和工具，因为他们所需的功能并不原生存在。RevenueCat 能处理基础功能，但在 50 万日活用户和精简团队的情况下，他们需要更多。

BibleChat 团队需要能够承载其规模的基础设施、一个与他们同步前进的合作伙伴、不会拖慢开发节奏的技术质量，以及他们此前一直自行构建的展示位置等原生功能。

他们开始寻找替代方案。在他们的规模下切换订阅基础设施不是一个轻率的决定，但维持现状同样有代价。

Marius 评估了 Adapty 的 SDK，质量差异立刻显现：

对于快速迭代的团队来说，SDK 质量至关重要。它影响构建、调试和发版的速度。团队此前已经在现有基础设施之上构建了自定义展示位置逻辑。借助 Adapty 的原生方案，他们可以完全移除这些自定义代码。

迁移耗时约一周。大部分时间用于移除 Adapty 以原生基础设施替代的自定义代码。

风险很高，但 Marius 对架构有充分的了解，能够自信地推进：

整个迁移过程没有收到任何支持工单或用户投诉。

历史数据迁移又花了两周时间。团队在 BigQuery 中保存了 RevenueCat 的原始日志，但需要转换属性格式。对于技术团队来说，这很简单——一个 SQL 查询加上处理时间即可。

直接收益体现在技术层面：更简洁的代码库、自定义代码的移除，以及更优的 SDK 架构。但更重要的是这套基础设施所释放的可能性。

团队从维护模式转向了优化模式。他们现在正在对付费墙进行 A/B 测试——这在之前是不可能的。接下来的计划是：使用 Adapty 的 Onboarding Builder 进行自动化留存测试。转变非常明显：更少的时间维护自定义代码，更多的时间用于优化。

BibleChat 选择了 Adapty，因为在他们所处的阶段，技术质量和合作伙伴关系同样重要。

对于快速扩展的小团队而言，你需要为优化而构建的基础设施——处理交易只是基本要求。你需要不会拖慢开发速度的 SDK 质量。你还需要一个愿意为你的增长投入的合作伙伴。