Buy SaaS Boilerplate Red Flags: 12-Point Checklist

本文由 Huifer 撰写，Solo 开发者，TanStack Ship 维护者。 在发布 TanStack Ship 之前，我花了 14 天审计了 11 个付费 SaaS 启动器。在这些仓库中，我发现了 37 个未固定的依赖项、6 个与商业 SaaS 使用冲突的许可证，以及 4 个超过 90 天没有公开回复的 Discord 社区。这些数字改变了我购买的方式，也改变了我构建的方式。这份检查清单就是我在每一次启动器落入收件箱时仍在运行的 12 项测试。

已验证来源： MIT License · AGPLv3 · Choose a License: AGPL · SPDX License List · SemVer · OWASP Top 10 · GitHub community profiles · NVD · npm audit · TanStack Start

最后更新： 2026-05-02 · 变更日志： 首次发布。12 项检查清单源自对 11 个付费启动器（代码、许可证、社区）为期 14 天的审计。

披露声明： 本篇为独立评测，无联盟链接，与文中提及的任何供应商均无实质性关联。

TL;DR

11 个付费启动器中有 6 个的许可证条款与典型商业 SaaS 使用存在冲突。

样本中共发现 37 个未固定的生产依赖项；首次发现"未连接"问题的中位时间为 18 分钟。

4 个社区在 90 天以上无公开维护者回复；11 个仓库中有 9 个的 bus factor 为 1。

版权许可、Commons Clause 和"终身"EULA 的出现频率比缺失 README 还要高。

运行下方 12 项测试，然后将结果与 TanStack Ship 功能对比。

最快损失三个月的方法，就是买了一套 SaaS 启动器，里面还藏着代码、许可证和空荡荡的 Discord 里的红牌警告。我把每个付费启动器当作不受信任的代码来处理，直到这三个层面都通过十二项测试。下面的测试流程就是我 14 天内对 11 款产品运行过的，也是 TanStack Ship 存在的原因。

第一轮排查不需要法律团队，也不需要安全公司。你需要一个 clone、一份许可证文件，以及在 git log 和 git grep 里花 20 分钟的诚实时间。如果启动器在本文 12 项测试中失败 3 项以上，我走人。如果通过了，我仍然会预留一周时间来拆掉演示用的 auth 和演示用的 billing，然后才开始写产品功能。更多买家视角的经验可以查看博客。

Buy SaaS Boilerplate Red Flags：20 分钟内可以用 grep 检出的代码问题

营销网站卖截图。仓库卖真相。我从 commit 年龄、lockfile 规范，以及 auth、billing 和多租户是真实函数还是注释开始查。OWASP Top 10 是安全视角；npm audit 和 NVD 是漏洞视角。两者都不能替代直接读代码。

未固定的依赖项和静默的大版本升级

在 11 个启动器的样本中，我发现 37 个生产依赖项使用了 * 或浮动大版本范围。这不叫"保持最新"。这叫下次在新机器上运行 install 时的供应链彩票。我还发现两个代码库中仍在使用 jsonwebtoken@8——在生态系统早已迁移之后——以及 Stripe SDK 被固定在某个大版本上，但该版本与 README 告诉你要用的控制台已经不匹配了。

健康的启动器会用 lockfile 固定版本，声明 engines，并在 Next、TanStack 或 billing SDK 发生大版本升级时发布变更日志。SemVer 不是可选的装饰。如果供应商交付的是 dependencies: { "next": "*" }，那他们就是在告诉你：他们自己都不跑他们卖的那套 install。

json

{
  "name": "red-flag-starter",
  "engines": {},
  "dependencies": {
    "next": "*",
    "stripe": "^10.0.0",
    "jsonwebtoken": "8.5.1"
  }
}

这个配置同时在三处测试失败：无 engines 声明、wildcard 版本号，以及已知已停止维护的 auth 库。把它和一个有 lockfile、有 engines.node 范围、有日期版本说明的仓库对比一下。我每次都选那个无聊但规范的仓库。

未连接的 Auth、Billing 和多租户

"包含 auth 和 Stripe"写在落地页上，在 11 个启动器中的 4 个里，实际只是一个复制的 Clerk 按钮和一个 webhook 路由——返回 200 状态码，注释写着 // TODO: provision tenant。我拿秒表计时。首次发现未连接路径的中位时间是 18 分钟。如果 checkout 没有创建 tenant 行、没有映射 plan、没有 gate 住 feature flag，你就不是买了 billing，而是买了一个截图。

多租户是那个破绽所在。检查每条涉及客户数据的查询是否都有 org_id（或等效字段）。如果 demo 用的是单一全局 user 和单一全局 subscription，那当你添加第二家公司时，你就得重写整个数据层。那次重写才是真正的项目。Boilerplate 只是一个延迟。

只存在于 README 里的测试

三个启动器宣传"完整测试套件"，但实际上 billing webhook、权限检查和租户隔离的断言一个都没有。README 徽章不是测试。我运行 package.json scripts 里实际存在的内容。如果 test 缺失、被 alias 到 echo、或在 CI 中被跳过，我记为失败。没有对资金路径测试的 boilerplate 是一个你将在生产环境中付出代价的隐患——而不是在购买价格上。

购买 SaaS Boilerplate 后会扼杀开发效率的代码味道

过了 happy-path demo 之后，我会 grep 查找 any、// @ts-ignore、硬编码的 API 密钥和 coming soon。这些出现次数多，预测的是你在类型漏洞和密钥泄露上损失的整整一周。我还会查找第二个 app router、第二个状态库和第二个 CSS 系统。声称"支持一切"的启动器通常没有一样东西做得好。选一个数据层、一个 auth 故事、一个 billing 故事。这与我在 TanStack Ship 功能页面和我们架构对比中记录的观点是一致的。

bash

# 20 分钟仓库健康度检查
git log --since="90 days ago" --oneline | wc -l
git grep -n "TODO\|FIXME\|coming soon" -- ':!node_modules' | wc -l
git grep -n "@ts-ignore\|: any" -- '*.ts' '*.tsx' | wc -l
npm audit --omit=dev

如果 90 天内的 commit 少于 10 个、TODO 数量达到数百、npm audit 在生产环境报告高危，我就不谈了，直接关掉标签页。

Buy SaaS Boilerplate Red Flags：阻止商业使用的许可证问题

无法上线的代码不是划算货。11 个启动器中有 6 个的条款与正常商业 SaaS 冲突：AGPL 无商业例外条款、Commons Clause 打着"MIT"的旗号、仅供评估的 EULA，或者"终身"许可证但保留了重新定价源码访问权的条款。看文件本身，不是看徽章。

我常打开的主要文本：MIT License、AGPLv3、Choose a License on AGPL 和 SPDX License List。SPDX 标识符是你不需要律师就能 grep 树的工具。缺少 SPDX 本身就是一个红旗。

渗入你产品的版权许可

托管 SaaS 启动器上的 AGPL 不是"开源"。网络使用可能触发你没预算到的源码披露义务。SSPL 和 Commons Clause 不是创始人看到绿色徽章时以为的那种 OSI 批准状态。我见过 README 写 MIT，但 /packages 里某个关键 package 是 AGPL 的情况。那个内层 package 才是随你的产品一起交付的东西。如果你无法替换它，你就继承了它的条款。

我不争论意识形态。我只讨论意外。如果你向银行出售 B2B SaaS，"你必须发布你的修改"是一个交易杀手。确认每个生产依赖项的许可证，而不只是根目录的 LICENSE。

暗含条款变更的"终身"优惠

2022 年的"终身更新"在 2025 年变成了"12 个月更新，然后收取席位费"——出现了两次。红旗不是供应商改变产品。红旗是许可证允许他们在付款后改变授权，而且没有保存你所接受的条款的副本。我会保存 EULA 的 PDF、日期和我购买时的 git tag。如果供应商不能给你一份有日期的授权，那你是在租，不是在买。

购买前如何审计 SaaS Boilerplate 许可证

这是我实际运行的长期排查步骤，按顺序：

识别根许可证和 workspaces 中的每个 LICENSE*。
将 SPDX ID 映射到 SPDX。在律师审阅前拒绝未知自定义文本。
搜索 AGPL、SSPL、Commons Clause、non-commercial、evaluation 和"source-available"。
完整阅读再分发、商标和"禁止竞争性 boilerplate"条款。有几个 EULA 禁止发布竞争的启动器——这没问题。但有几个也禁止发布与供应商自有 SaaS 同一类别的产品——这是陷阱。
确认你是否可以在供应商消失后移除版权头、重塑品牌并保留代码。

bash

# 许可证和版权许可扫描
git grep -i -n "AGPL\|SSPL\|Commons Clause\|non-commercial\|evaluation only" \
  -- LICENSE* COPYING* package.json README.md
npx license-checker --production --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC;0BSD"

如果 license-checker 报错，你面对的不只是许可证问题。你有一个依赖项问题，而这个依赖项问题会在客户提问的那天变成许可证问题。

Buy SaaS Boilerplate Red Flags：预示被放弃的社区信号

一个漂亮的仓库配一个维护者和一个沉默的 Discord，是一颗定时炸弹。11 个启动器中有 9 个的 bus factor 为 1。4 个社区在 90 天以上无公开维护者回复。我用 GitHub 自家的 community profile 文档作为基准：README、许可证、安全策略和提交 issues 的方式。缺少这些不叫"极简"，叫无人维护。

Issue 速度、响应时间和 Bus Factor

我不需要 1000 个 star。我需要的是当 auth 在周一坏掉时有真人回复的证据。查看最后 20 个 issues 首次回复的中位时间。查看是否每次 commit、每条评论和每条 tweet 都是同一个 GitHub handle 写的。Bus factor 为 1 但代码量小且许可证允许 fork 的话，还可以勉强生存。Bus factor 为 1 加限制性 EULA，那就是人质处境。

要求购买后才能看到活跃度的私人 Discord 是利益冲突。我仍然会要求只读窗口或公开 issue 追踪器。如果唯一的存活证明是一份营销通讯，我就把社区判为失败。

变更日志表演 vs 真正的 SemVer

变更日志只写"大量修复"而没有版本号，那就是表演。我要的是遵循 SemVer 的带标签发布、在 auth 或 billing 变更时有迁移说明，以及一个指向 NVD 实践（如披露、打补丁、注明日期）的安全策略。如果供应商静默打补丁并重新打 latest 标签，你就无法固定版本，也无法审计。

预示启动器被遗弃的社区健康度信号

来自 11 个启动器集合的预测信号，按重要性排序：

最后一次 commit 超过 90 天，但营销网站仍写着"每周更新"。
同一个 bug 被报告了三次，没有标签，没有负责人。
路线图页面满是"2024 年第三季度"，但从未更新。
欧洲和美国工作时间 Discord 在线人数只有个位数，反复出现。
没有 SECURITY.md，没有咨询流程，在贡献文档中没有提及 npm audit。

以上任意两条同时出现，我就假设购买后第二天我就是维护者。如果许可证是 MIT 且代码量小，这还可以接受。如果要价 $299 再加上禁止 fork 条款，那就不可接受了。

我仍在运行的 12 项尽职调查检查清单

每项评分为通过/失败。3 项失败：走人。这套清单我原封不动地用在 11 个启动器上，也用在了最终成为 TanStack Ship 的那个仓库上。

过去 90 天内有 commit，有 lockfile，不只是 README 编辑。
声明了 engines；生产框架和 billing SDK 上没有 *。
npm audit --omit=dev 无高危/严重漏洞，或有记录在案的例外。
Auth、billing 和 tenant 配置端到端已连接，不是 TODO。
Webhook、权限和租户隔离有测试。
根许可证已识别并有 SPDX；workspaces 中无意外的 AGPL/SSPL/Commons Clause。
EULA 授权有日期，供应商消失后仍然有效；无静默条款变更。
已完整阅读再分发和"不竞争"条款。
Bus factor 已说明或显而易见；issue 回复在公开追踪器上可见。
SemVer 标签和真正的变更日志，不是"大量修复"。
有 SECURITY.md，路径匹配 OWASP 现实，不是徽章。
一个数据层、一个 auth 故事、一个 billing 故事——不是"带来十一套框架"。

启动器通过之后，我仍然会安排一周的拆解时间。启动器失败之后，我不会"也许下周修一下"。我会看定价里我已经信任的栈，或者自己动手构建薄薄的一层。买家教育只有在你能指向一个同样设计来通过这些测试的产品时才有说服力。TanStack Ship才是诚实交接。

什么时候走人，什么时候谈判

当失败项是文档、缺少 engines 字段或可以本周修复的变更日志时，可以谈判。当失败项是核心包里有版权许可、billing 未连接或社区已经沉寂时，走人。这些问题不会因为创始人回了你的 DM 变好。只有代码和授权都改变了，而且是公开改变，才会好。

将测试映射到 TanStack Ship

我构建 Ship 就是为了在第 4、6、12 项上不用自欺。TanStack Start、类型化数据加载和单一 billing 路径，正是那些"支持一切"但没有一样做好的启动器的反面。用这个检查清单开着另一个标签页读功能列表、对比矩阵和定价。如果 Ship 在你在意的测试上失败了，从关于页面给我发邮件。我宁愿丢一单生意，也不愿继承我已经数过的 37 个未固定依赖项。

通过启动器后我仍然预留的预算

通过测试不等于上线日期。我仍然预留一周来删除演示租户、轮换所有密钥、重写 onboarding 文案，让它写我的产品而不是供应商的名字。我还会用干净的 CI 镜像重新运行 npm audit --omit=dev，而不是用我笔记本的缓存。如果那一周让你觉得太贵了，那启动器从来就省不了你的钱。它只是把账单藏到生产环境才揭开来。

常见问题

购买付费启动器时，MIT 许可证够用吗？

不够。根目录的 MIT 是必要条件，不是充分条件。你仍然需要 workspaces 上的 SPDX、与营销一致的授权（"终身"vs 12 个月），以及一份 license-checker 能解释的依赖树。根目录 MIT 加内部 AGPL package，实际上就是 AGPL。在假设"开源"意味着"可以闭源发布"之前，先读一下 AGPLv3。

购买前应该信任多新的 commit？

我要 90 天内有实质性的 commit，不是空白行。Mature 的启动器可以安静——如果 issues 有回复、依赖项是当前版本的话。仓库安静 + Stripe 大版本过时 + Discord 空荡 = 被遗弃。用 GitHub community profiles 作为底线，不是上限。

如果供应商用的是自定义 EULA 而不是 OSI 呢？

自定义可以——如果它简短、有日期、并且授予你出售 SaaS 所需的权限：运行、修改、移除品牌、供应商倒闭时保留代码。如果它可以在购买后变更、禁止同类别竞争、阻止 fork，那就是失败。把 PDF 保存下来。如果他们要结账后才肯发条款，这是红旗，不是销售流程。

我可以转售用 Boilerplate 构建的产品吗？

最终用户 SaaS 通常可以，"这是另一个 Boilerplate"通常不行。区别在 EULA，不在 Twitter 帖子。11 个启动器中有两个用范围足够广的语言禁止了同类别竞争产品，足以吓到一个谨慎的律师。如果转售或白标在你的计划里，付款前先让那条条款书面化。然后在一个你真正能拥有的技术上构建——这才是 TanStack Ship的意义。

如果你带着"购买 SaaS Boilerplate 的红牌警告"来到本文，而不是带着生产环境中的问题，你已经拥有了我在那 14 天审计第一天没有的优势。运行 12 项测试。保留一份有日期的许可证。从那些在 Stripe 轮换 webhook 时必须响应的人那里，要求一个公开的脉搏。当你想要一个构建来通过这些测试的启动器，而不是一个赌你永远不会 clone 仓库的落地页时，从 TanStack Ship 开始，只有在你用 grep 自己验证过之后才到定价付款。