2026 年如何构建一个 SaaS 产品？
取决于产品，但可靠的路径是：从付费客户愿意用的最小产品开始，只建没有它就跑不起来的基础设施：认证、租户感知的数据模型、幂等 webhooks 的计费、事务性邮件和后台任务。2026 年，多数团队用 supastack 这样的生产级脚手架跳过几个月的无差异化管道工——它在一个测试完备的代码库里交付认证、组织工作区、八个支付服务商、AI 成本控制，以及 Web、移动和桌面客户端。差异化功能自己写，管道买或复用。
第 1 步：圈出最小的可售产品
每个失败的 SaaS 都栽在同一个起点错误：为它可能成为的产品而建，而不是为这个月能赢下的客户而建。写下一句话，"{客户} 为 {结果} 付 {价格}"，删掉每一个不交付这个结果的功能。登录页、定价表、工作区切换器都不是产品，它们是入场券。
尽早决定产品真正需要哪些端：多数工具一个 Web 应用就够；工作在办公桌之外发生才加移动端，工作与文件或系统相邻才加桌面端。现在选端就是在定架构——给单应用代码库后补第二个客户端，是年轻产品最昂贵的一次改动。
- 写代码前先写下 {客户} / {价格} / {结果} 这句话。
- 列出付费用户每周都会打开的三个界面；那就是 MVP。
- 有意识地选端：只要 Web，还是 Web 加移动/桌面。
第 2 步：认证与账户
登录只占认证的百分之十五。剩下百分之八十五是会话吊销、OAuth 账户绑定、双因子与 passkeys、密码重置、管理员模拟，以及环绕这一切的邮件流。选 Better Auth 或 Auth.js 这样全包的库，别自己搓加密，并且把用户表留在自己的数据库里，按 MAU 计费才永远不会变成人质谈判。
只要有客户会是公司，现在就把组织建模进去：个人与团队工作区、邀请、owner/admin/member 角色。日后再补租户等于迁移每一条查询。登录界面之后的完整清单见 登录表单之外的认证。
第 3 步：租户感知的数据模型
Schema 是产品的记忆。用贴近 SQL 的 ORM——Drizzle 或 Prisma，从第一天起给每一行租户数据挂上 workspace_id。作用域强制两遍：应用代码一遍、Postgres 行级安全又一遍，漏写的 WHERE 退化为“拒绝访问”，而不是数据泄露。
完整模式——工作区级键、RLS 策略和证明它们的测试——见 Postgres RLS 与工作区认证。ORM 选型本身见 Prisma vs Drizzle for SaaS。
第 4 步：扛得住网络的计费
计费是披着定价页的分布式系统问题。服务商重试 webhooks；你的处理器必须幂等：先存事件、按 ID 去重、再履约。只建模一个原语——权益（entitlement），让 Stripe、Lemon Squeezy、Polar、Paddle 或 RevenueCat 都归一到它，第二家服务商就是改配置，不是重写。
账本模式见 幂等计费 webhooks；选 MoR 还是 Stripe 之前先读 SaaS 支付服务商对比。
第 5 步：邮件、后台任务与可观测性
事务性邮件是认证与计费的一部分，送达率配置（SPF、DKIM、DMARC）不是可选项。后台任务需要会重试的队列：开通、报表生成、AI 调用，以及任何不能被合上的笔记本杀死的工作。看不见的东西没法运营：结构化日志、错误追踪和审计记录属于第一周，而不是第一次事故之后。
第 6 步：有成本控制的 AI 功能
加个聊天框容易，养得起才是设计问题。模型调用走适配器，服务商随时可换；让工作区自带密钥（静态加密）；按价格目录执行工作区级用量预算——客户用量大的月份，账单记在他们头上，不是你。
诚实的捷径：做产品，不做管道
上面这些都被解决过无数次了。supastack 这样的生产级脚手架交付的是整套已集成的技术栈：Better Auth、组织工作区、幂等账本后的八个 Web 计费服务商、事务性邮件、Trigger.dev 任务、带 BYOK 预算的 AI 路由器，以及与 Web 应用共享类型化包的 Expo + Tauri 客户端，由 144+ 测试文件背书。
自建还是购买的账在 入门套件还是从头开始 里算过；简版结论：客户只为只有你能做的功能付钱。走脚手架路线的话，之后的事见 SaaS 发布清单。