用脚手架还是从零开始？先想清楚你要拥有什么

把产品工作与重复的基础设施分开

先列出让你的产品有用的功能，再列出它运转所需的基础设施。研究工作流可能是独特的；会话处理、客户拥有的记录与订阅访问通常不是。这份清单比数脚手架首页上有多少功能更能帮你做评估。

第二张清单比看起来长得多。大多数 SaaS 产品都在重复实现同样的一打部件，而且每一个都必须与其他部件正确集成，产品才能开始做任何事情。

从零开始让你直接掌控这些选择，但也要自己负责集成与维护。脚手架改变的是起点。你仍需要理解它的代码，并验证它对你的产品、团队与部署所作的假设。

• 身份：登录方式、会话、账户找回。
• 工作区：记录归属、邀请、成员角色。
• 计费：结账、Webhook、权益、取消。
• 后台任务：队列、重试、定时、状态跟踪。
• 交付：事务邮件、文件存储、部署。

比较总成本，而不是标价

脚手架的价格一目了然；从零开始的成本摊在几个月里。诚实地算一遍：组装认证、计费、任务和部署花掉的几周；这些组装自带的集成 bug；以及之后每次供应商更新触发的维护。

脚手架的成本是学习和改造别人写的代码：读它的约定、替换示例内容、偶尔掰弯它画的边界。如果下面的检查进行顺利，这笔交换通常比重造同样的管道便宜；如果进行得糟糕，那是一个不该忽视的警告——今天读不懂的边界，就是明年的生产事故。

评估你将继承的代码

跑一遍安装说明，跟着一条记录从界面走到持久化。检查授权是否位于服务端边界、配置是否经过校验、供应商凭证是否留在客户端包之外。读一个失败路径的测试，而不只是演示界面。

留意示例产品与基础设施变得不可分的地方。如果移除一个演示功能需要改动认证或计费行为，未来的产品工作可能比初始安装看起来更困难。在 supastack 中，使用方产品把领域逻辑留在 Starter Core 之外，通过配置与契约连接——项目结构指南标出了这条线的位置。

• 每一个没有文档、只能自己摸索出来的安装步骤。
• 授权在哪里执行，是逐路由还是系统性的。
• 是否存在反向测试——跨工作区读取、重放的 Webhook——以及它证明了什么。
• 密钥放在哪里，以及是否有任何一个进了客户端包。
• 当你试图删掉一个演示功能时，基础设施会发生什么。

先做决定前先跑起来

在承诺之前，先到仓库里待上一天。在 supastack 里这意味着 corepack pnpm install、一份配置好的 apps/web/.env.local，以及本地参考流程：登录、查看权限、提交任务、读取结果。然后 pnpm verify:local 会在 fake 供应商上跑完黄金路径，不需要任何凭证——本地设置指南走查了整个顺序。

然后故意弄坏点什么。同一个任务提交两遍。用错误的工作区调一个 API 路由。重放一个 Webhook。能把普通失败处理得漂亮的 starter，比功能清单更长的值钱——因为在你机器上都弄不坏的东西，迟早要在生产环境里调试。

把取舍说清楚

当脚手架的既有边界符合你的需求、且你能讲清将要依赖的流程时，就选脚手架；当产品约束会迫使脚手架的假设被反复修改时，就自建基础。两种选择都可以是合理的；关键问题是你的团队扛得住哪种维护负担。

为替换示例内容、配置集成、审查数据归属与测试部署预留时间。一个能编译的仓库只是生产验收的起点。发布前，请在客户将要使用的环境中验证真实的登录路径、计费生命周期与恢复行为——发布检查清单逐条列了出来。如果底层技术栈也还没定，如何选择 SaaS 技术栈覆盖了逐层评估；这两个决定互为参照。

关于脚手架的常见问题

买还是造的争论总能激起强烈的观点。这些问题才真正推动决定。

• 正经产品用脚手架有风险吗？ —— 大量生产环境的 SaaS 跑在买来的地基上。风险不在脚手架本身，而在继承你从没检查过的代码。在依赖边界之前先把它们读一遍。
• 怎么判断一个样板还在被维护？ —— 看最近的提交、文档化的更新路径、覆盖失败场景的测试，以及用细节而非路线图承诺来回答的 issue。
• 如果脚手架的选择和我不一致怎么办？ —— 先分清偏好和约束。给 UI 换皮很便宜；与会话模型或租户边界较劲可不便宜。结构性错配就是自建的理由。
• 以后还能离开脚手架吗？ —— 代码归你所有，没有什么可迁出的——真正的问题是，当你不断修改时它的管道还是不是资产，这正是产品代码与基础设施代码可分离之所以重要。
• 脚手架到底能省多少时间？ —— 大致等于认证、计费、任务和部署本会花掉的那几周，减去学习和改造所继承代码需要的那几天。