用自家引擎砍掉年费360欧的SaaS订阅

从“买”到“删”：一次预订功能的去SaaS化实践

作为一家SaaS公司的CEO，我最近做了一件让自己很痛快的事：在某个晚上，合并了一个删除自家利润表（P&L）上一行支出的Pull Request。这行支出是Cal.com的订阅费，每月30欧元，用于官网“Book a 15 Min Demo”按钮背后的预约引擎。现在，这个功能被我们自己的产品替代了，而整个过程只花了大约两小时，涉及四个PR。

为什么当初选择付费购买

时间回到7月中旬，我们需要在官网落地演示预约功能。当时的选择是“买”而不是“造”，这个决策现在看来依然正确。预约功能看起来简单，实则复杂：跨真实日历的时段计算、防止双重预订的竞态条件、邀请发送、取消和改期，每一步都是坑。

Cal.com提供了欧盟数据驻留实例和官方React嵌入组件，集成很顺利。但更关键的原因是Google OAuth的验证问题：如果自己开发，需要连接Google Calendar，而未验证的OAuth应用只能处于“测试”模式，刷新令牌每7天过期一次。一个日历连接每周静默失效的公开预约页面，不是销售漏斗，而是bug报告生成器。Cal.com已经完成了验证流程，所以我们租用了他们的能力。

两个改变局面的转折点

7月底，我们为产品本身发布了真正的预订引擎：经纪人的终端客户可以直接在聊天内预约咨询电话。这个引擎包含Google和Microsoft适配器、策略驱动的时段计算、供应商发送的邀请、双重预订保护，以及每15分钟检查会议变动并同步的定时任务。这是为付费客户打造的引擎。

上周，Google的OAuth验证通过了，7天令牌过期的问题彻底消失。至此，付费购买Cal.com的最后一个理由也不存在了。剩下的，只是一个每月30欧元的习惯性支出。

复用而非重建：两小时背后的真相

很多人可能会误解，以为我在两小时内从头构建了一个预订系统。事实并非如此——我只是复用了两周前为产品发布的引擎。演示预约漏斗成了这个引擎的第二个租户，真正的新代码很少：两个公共API路由、一个管理页面、一个现有弹窗中的调度器面板。

有一个设计决策值得偷师：公共路由完全不携带租户参数。聊天流程需要签名令牌，因为访客必须绑定到特定经纪人的租户；而营销页面只有一个目的地，没有需要授权的对象，因此也就不存在可攻击的令牌机制。路由从服务器上的环境变量解析公司信息，请求只携带时段、姓名和邮箱。更少的机制，意味着更小的攻击面。

两个Bug：实时验证的价值

我不想假装整个过程一帆风顺。有两个bug在发布后一小时内被捕获，都是通过实时验证发现的，而不是测试套件。

Bug 1：静默无操作。 管理后台的“连接Google Calendar”按钮点击后没有任何反应。原因是OAuth回调在特定条件下没有正确刷新状态，导致界面看似正常但实际未连接。

Bug 2：预约确认延迟。 在某些边缘情况下，访客提交预约后，确认邮件会延迟发送，因为定时任务与即时通知之间的同步存在竞态条件。

这两个bug都是真实用户触发后迅速定位的。这提醒我们：对于这类关键漏斗功能，实时监控和快速响应比过度依赖测试覆盖更实际。

对开发者的启示

这次迁移的核心价值在于：不要为自家产品已具备的能力重复付费。如果你正在使用第三方服务，而自己的产品恰好实现了类似功能，不妨评估一下替换成本。很多时候，复用现有引擎的边际成本极低，而收益是每月固定的现金流节省和更少的供应商依赖。

对于AI辅助开发，这次实践也证明：Claude Code这类工具的价值不在于“两小时写完代码”，而在于帮你快速完成“最后两公里”——把两个月来积累的架构决策和复用逻辑，高效落地为生产代码。