一个人做 SaaS 产品之后，我对架构复杂度的一些真实感受，分享给大家
我这几个月一直在独立做一个 SaaS，叫 [PigeonPod Cloud](https://pigeonpod.cloud/)，主要是把 YouTube 频道和播放列表转换成私人播客 RSS 的 SaaS。用户订阅内容源以后，系统会自动同步新内容、下载媒体文件，并通过私人 RSS 提供给播客客户端。
产品上线 3 个多月，我一个人在开发，维护过程里，真切的感受到了不少和之前在公司里做项目很不一样的点。写了一篇简单的文章把这些感受和经验分享给兄弟们，希望能给也在做或者想做个人产品的朋友一些启发，也欢迎一起交流讨论。
这个产品目前还很早期，但已经有一些真实用户：
- 约 1300 名注册用户
- 累计完成约 61000+ 个下载任务（视频和音频都有）
- 每天完成 16000+ 多次订阅源同步
做这个产品以后，我越来越觉得，架构设计的核心问题不是“怎么设计得更完整”，而是“哪些复杂度值得承担”。对于一个人维护的 SaaS，每一个组件、每一个服务、每一个模块，最后都会变成维护责任。它们需要部署、监控、升级、排错，也需要在业务变化时继续修改。
**维护成本会在产品功能基本完成上线后，迅速超过开发成本。** 文章里写了三个例子。
第一个例子是后端边界。
我把 API 服务和下载 worker 拆成了独立运行单元。因为下载任务会消耗大量网络、CPU、内存和本地存储，也容易受到外部平台限流影响。如果它和 API 服务跑在一起，后台任务的波动就可能影响用户请求。
但是，我没有继续把系统拆成微服务。当前阶段，共享数据库和进程内调用的成本更低，排错路径也更短。对我来说，这比“架构看起来更标准”重要。
第二个例子是删功能。
PigeonPod Cloud 早期做过一个站内内容消费模块，包括播放队列、收藏、云端播放进度等功能。这个模块已经上线，也做得很完整了。
后来我通过数据发现，实际使用率很低。它的基础设施成本接近零，但维护成本不是零。只要这个模块还在，未来每次改数据模型、改播放器、迁移前端状态，都要继续考虑它。最后我把它删掉了。这个变更涉及 94 个文件，删除约 5700 行代码和 6 张表。
这件事给我的教训是：已经写完的代码不是资产，只有继续产生价值的代码才是资产。这一点在 AI Agent 写代码越来越快的时代，我认为尤其重要，保持专注会成为未来构建产品的核心能力之一。我会专门再写一篇文章来讨论这个事情。
第三个例子是云服务账单。
早期 SaaS 的固定成本很重要。账单越高，产品可以继续试错的时间就越短。
所以我把核心用户路径放在云服务上，把 Loki、Grafana、Plausible、JobRunr dashboard 和分析库放在家庭服务器上（一个几年前买的 mini 小主机）。它们短暂离线不会影响用户使用，但可以明显降低固定成本。
这不是通用建议，只是当前约束下的选择。等产品规模、收入情况变化以后，答案可能也会变化。
我越来越觉得，**架构成熟度不是能够在项目开始时就能设计出完整的架构，更不是使用了多少时髦的技术，而是知道什么适合自己的项目，为什么引入某项复杂度，它解决什么问题，以及什么时候应该停止为它付费。**
文章原文在这里： [复杂度从来不是免费的：一个独立开发者的 SaaS 架构取舍](https://zemo.bio/zh/posts/complexity-is-never-free-architecture-trade-offs-from-building-a-saas-alone/)
欢迎兄弟们交流讨论。
---
原文链接：[点击查看](https://www.v2ex.com/t/1228468)
产品上线 3 个多月，我一个人在开发，维护过程里，真切的感受到了不少和之前在公司里做项目很不一样的点。写了一篇简单的文章把这些感受和经验分享给兄弟们，希望能给也在做或者想做个人产品的朋友一些启发，也欢迎一起交流讨论。
这个产品目前还很早期，但已经有一些真实用户：
- 约 1300 名注册用户
- 累计完成约 61000+ 个下载任务（视频和音频都有）
- 每天完成 16000+ 多次订阅源同步
做这个产品以后，我越来越觉得，架构设计的核心问题不是“怎么设计得更完整”，而是“哪些复杂度值得承担”。对于一个人维护的 SaaS，每一个组件、每一个服务、每一个模块，最后都会变成维护责任。它们需要部署、监控、升级、排错，也需要在业务变化时继续修改。
**维护成本会在产品功能基本完成上线后，迅速超过开发成本。** 文章里写了三个例子。
第一个例子是后端边界。
我把 API 服务和下载 worker 拆成了独立运行单元。因为下载任务会消耗大量网络、CPU、内存和本地存储，也容易受到外部平台限流影响。如果它和 API 服务跑在一起，后台任务的波动就可能影响用户请求。
但是，我没有继续把系统拆成微服务。当前阶段，共享数据库和进程内调用的成本更低，排错路径也更短。对我来说，这比“架构看起来更标准”重要。
第二个例子是删功能。
PigeonPod Cloud 早期做过一个站内内容消费模块，包括播放队列、收藏、云端播放进度等功能。这个模块已经上线，也做得很完整了。
后来我通过数据发现，实际使用率很低。它的基础设施成本接近零，但维护成本不是零。只要这个模块还在，未来每次改数据模型、改播放器、迁移前端状态，都要继续考虑它。最后我把它删掉了。这个变更涉及 94 个文件，删除约 5700 行代码和 6 张表。
这件事给我的教训是：已经写完的代码不是资产，只有继续产生价值的代码才是资产。这一点在 AI Agent 写代码越来越快的时代，我认为尤其重要，保持专注会成为未来构建产品的核心能力之一。我会专门再写一篇文章来讨论这个事情。
第三个例子是云服务账单。
早期 SaaS 的固定成本很重要。账单越高，产品可以继续试错的时间就越短。
所以我把核心用户路径放在云服务上，把 Loki、Grafana、Plausible、JobRunr dashboard 和分析库放在家庭服务器上（一个几年前买的 mini 小主机）。它们短暂离线不会影响用户使用，但可以明显降低固定成本。
这不是通用建议，只是当前约束下的选择。等产品规模、收入情况变化以后，答案可能也会变化。
我越来越觉得，**架构成熟度不是能够在项目开始时就能设计出完整的架构，更不是使用了多少时髦的技术，而是知道什么适合自己的项目，为什么引入某项复杂度，它解决什么问题，以及什么时候应该停止为它付费。**
文章原文在这里： [复杂度从来不是免费的：一个独立开发者的 SaaS 架构取舍](https://zemo.bio/zh/posts/complexity-is-never-free-architecture-trade-offs-from-building-a-saas-alone/)
欢迎兄弟们交流讨论。
---
原文链接：[点击查看](https://www.v2ex.com/t/1228468)
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞