Fivetran 用 AI 代理自建状态页，替代年费 6.5 万美元的 SaaS

Fivetran 两名工程师 Valentina Mačković 与 Jelena Kostic 用约 4 个月时间，借助 Claude AI 编码代理从需求文档一路走到生产环境，成功替代公司此前使用的、年成本约 6.5 万美元的 Atlassian Statuspage SaaS 产品。新系统已上线承担 Fivetran 公开状态页的运行，并为约 2.6 万名通知订阅用户提供服务。

原方案的成本与痛点

Fivetran 此前在 Atlassian Statuspage 上做了大量定制化扩展，包括基于 Google Cloud Functions 的可用性计算、BigQuery 数据仓库中的事故追踪同步等。但随着业务发展，原方案逐渐显露出多个问题：

成本高昂：每年约 6.5 万美元，主要由按订阅用户数计费的模式驱动，公司有约 2.6 万名订阅者
运维负担：每年至少消耗约 1 万美元的工程师时间用于故障排查与维护
性能不稳定：页面加载缓慢，有时首次访问即失败——而状态页的核心价值恰恰是在服务异常时仍可访问
静默失败：曾出现更新未正确传播却未被发现的情况
接口限流：公司内部的自动化流程曾触发供应商 API 速率限制

为何选择自建

状态页本身复杂度不高（少量读取接口、一个管理面板、一个邮件队列），但承担生产级影响：一旦 Fivetran 服务出现故障，成千上万客户会查阅状态页，单次事故通知邮件可达 5 万封以上。这种"低复杂度、高风险"的特征，正是 AI 编码代理适合切入的场景。

促使团队决定自建的三个关键考量按权重排序：

对可靠性的掌控：依赖第三方意味着可靠性上限被供应商锁定，团队无法修复性能瓶颈
计费模型与产品形态不匹配：本质上是一个邮件列表，却按订阅用户数付费，成本随客户增长线性上涨而价值并未等比例增加
验证组织能力：能否由 2 名工程师借助 AI 代理把 PRD 做到生产可用——如果可行，这将是一项可复用的能力

团队也明确指出，这一结论并不意味着 SaaS 整体被取代。Fivetran 自家产品同样是 SaaS。状态页只是"通用产品中一个细分的、规格明确的小切片"，对这类场景，自建一方的成本曲线已被 AI 显著压低。

代理角色化分工与构建流程

在正式写代码之前，团队花了大量时间搭建一套面向 AI 代理的"入职体系"：

项目规则文档 CLAUDE.md：定义项目规则与一个 16 步的开发流程
6 个代理角色，各自拥有独立的初始化文件：
- 项目负责人：负责任务分发与排序，不直接写代码或文档
- 产品经理：负责需求范围、任务拆分与审批
- 软件架构师：负责技术设计、API 契约、代码评审与合并
- 软件工程师（前端/后端）：分别负责 Java 后端与 React/TypeScript 前端实现
- QA 工程师：负责端到端测试与缺陷分诊
- SRE 工程师：负责部署、监控与 GCP 运维
技能库（skills）：覆盖后端约定、前端模式、整洁代码、JUnit、Bazel、Nx、QA 与版本控制的可复用指令集
协作机制：代理之间彼此通信；遇到不确定时做出有记录的最佳决策而非停滞等待人类介入；每个功能使用独立 git 分支与 worktree，多个代理团队可并行推进互不冲突

团队还为代理提供了完整的规格化输入：正式的 PRD 与 TDD 文档（转换为 Markdown）、定义每个端点的 OpenAPI schema，以及一套 Figma UI 设计资产。这种"先文档后代码"的方式让大量设计实现可以自动化完成。

Fivetran 表示会继续公开后续迭代中的实际成本、工程时间与失败经验，以帮助行业判断"AI 替代特定 SaaS"这一命题的真实边界。