SaaS 早期技术债：哪些可以欠，哪些第一天就不能欠

开场：早期可以粗糙，但不能没有底线

SaaS 早期一定会欠技术债。因为你还不知道客户到底买什么，过早追求完美架构会浪费时间。

但“先快起来”不等于什么都能先凑合。某些债以后能还，某些债会直接限制销售、破坏客户信任，甚至让你无法修复数据。

关键不是完全不欠债，而是知道哪些地方可以先简单，哪些地方从第一天就要有底线。

可以欠的债

早期可以接受的技术债，通常有一个特点：它影响开发效率或局部体验，但不破坏客户数据和信任。

例如：

• 后台页面样式不够精致。
• 部分操作需要管理员手动执行。
• 报表查询还不是实时刷新。
• 内部配置入口不够友好。
• 某些边缘场景先用脚本处理。
• 权限角色先做少量固定类型。

这些问题会带来不便，但只要团队知道在哪里、影响哪些客户、如何临时处理，就可以暂时接受。

不能欠的债

有些债从第一天就不该欠。

这些能力不一定要做得复杂，但必须有最小可用版本。

早期架构要服务变更

不要一开始就设计微服务、插件市场、多区域部署。早期最重要的是让业务变化成本低。

一个实用原则是：核心业务概念要清楚，外围实现可以简单。

例如工单类 SaaS，至少要把这些概念建模清楚：

• 租户。
• 用户。
• 角色。
• 工单。
• 状态。
• 评论或处理记录。
• 附件。
• 操作日志。

如果核心概念混在一张万能表里，后续每个功能都会越来越难做。

相反，缓存、异步队列、复杂监控、分库分表，可以等到确实需要时再引入。

给技术债建一张债务表

不要让技术债只存在于开发者记忆里。可以维护一张简单表：

债务表的价值，是让团队知道自己在主动取舍，而不是被动混乱。

用触发条件决定是否还债

早期不要因为“看着不优雅”就还债。还债要有触发条件：

• 某问题每周重复出现。
• 某问题阻碍成交。
• 某问题导致客户不能自助完成关键流程。
• 某问题影响数据安全或合规承诺。
• 某问题让开发新功能明显变慢。

没有触发条件的重构，容易变成工程洁癖。真正的技术债管理，是让工程投入服务业务风险。

最小工程底座清单

如果你准备开始第一个可收费版本，至少检查这些项：

• 生产和测试环境分离。
• 数据库有自动备份和恢复演练。
• 关键表有创建时间、更新时间和操作者记录。
• 关键删除操作有二次确认或软删除。
• 错误日志能定位请求、用户和租户。
• 部署过程可重复，不依赖单台机器手工操作。
• 有一个管理员入口能处理客户的基础支持问题。

这些不是大公司流程，而是小团队避免事故的最低成本。

常见误区

第一个误区，是用“以后再说”逃避安全和数据问题。客户把业务数据交给你，就已经在评估信任。

第二个误区，是过早追求大架构。架构复杂会放大沟通和维护成本。

第三个误区，是没有记录临时方案。临时方案用久了，就会变成没人敢动的黑箱。

第四个误区，是把重构当成阶段目标。重构应该服务成交、留存、性能或风险，不应该只是为了好看。

早期 SaaS 可以欠债，但要欠得清楚、可控、可还。底线守住，速度才有意义。