独立开发最容易出现一种错觉：只要把技术栈配齐，产品就完成了一半。
我也曾把前端框架、数据库、认证、支付、分析、邮件、监控列成一张很长的表。表越完整，动手越安心；但那种安心往往来自“我在建设”，而不是“有人需要”。工具清单解决的是选择焦虑，产品要解决的却是用户愿不愿意改变现有做法。
后来我的判断变得更朴素：独立开发者真正稀缺的是把有限注意力押在正确问题上的能力，代码能力反而不那么稀缺。 技术栈无需显得现代；在证据还很少的时候，它更应该便宜、快速、可撤销。
本文是一条从问题验证到产品维护的路线。它不承诺某个框架永远最好，也不记录会随套餐变化的价格和免费额度。涉及平台能力的边界，以 2026-07-31 可查到的官方文档为准；真正采用前，请再次核对区域、配额、条款和数据处理协议。
一、先验证问题，别先验证技术
一个值得做的问题，至少要同时出现三个信号：
- 具体的人：不是“所有创作者”，而是“每周要整理三次客户访谈的中文 SaaS 创始人”。
- 正在发生的代价：对方已经在用表格、外包、复制粘贴或忍受错误；没有替代行为的问题，通常也没有购买紧迫性。
- 可观察的承诺：愿意给数据、约下一次试用、介绍同事，最好愿意付费。口头说“挺好”不是承诺。
我会先做十次左右的问题访谈，但不机械追求样本数。访谈只问过去：上一次什么时候发生、现在怎么处理、花了多久、失败会怎样。尽量少问“你会不会用一个……”，因为人很擅长礼貌地支持并不存在的未来。
然后做一次礼宾式交付：表单收集输入，我在后台手工完成核心结果，再把结果交还给用户。若连手工服务都没人愿意反复使用，自动化只会让错误方向跑得更快。
验证关卡
在写正式产品前，我希望拿到以下证据中的至少两项：
- 同一类用户在不同场景重复描述同一个问题；
- 用户主动提供真实数据或投入配置时间；
- 手工结果被实际使用，而不只是被称赞；
- 有人愿意预付、订阅或签署明确的试用承诺；
- 用户在没有提醒的情况下再次回来。
没有通过，就缩小人群或换问题。沉没成本不是继续开发的理由，它只是更昂贵的一条反馈。
二、先画最小闭环，再选最小技术栈
MVP 不是功能少的正式产品，而是验证一个高风险假设的最短闭环：
目标用户进入 → 提供关键输入 → 得到核心结果 → 采取下一步行动 → 我能观察结果
闭环之外的功能暂时不做。团队空间、主题皮肤、复杂权限、插件市场、多区域容灾，可能都正确，只是此刻没有证据证明它们应该排在第一次交付之前。
我的默认原则是“一种主要语言、一个关系数据库、一个部署路径”。如果我已经用 Go 或 Python 熟练解决后端问题，就不会为了流行把业务拆成多个运行时；如果页面和 API 都能由一个成熟全栈框架承载，也不会提前引入微服务。对一人团队而言，认知切换本身就是成本。
按阶段决策表
| 阶段 | 要消除的不确定性 | 够用的实现 | 暂时不做 | 进入下一阶段的信号 |
|---|---|---|---|---|
| 问题探索 | 谁痛、何时痛、为什么现在解决 | 访谈、落地页、表单、手工服务 | 完整账户系统、自动化 | 用户投入时间、数据或钱 |
| 可收费原型 | 核心结果是否有价值 | 单体应用、单库、人工运营后台 | 微服务、复杂角色、原生 App | 有人重复使用或付款 |
| 可重复交付 | 能否稳定服务一小群人 | 基础测试、CI、日志、备份、支付回调 | 多区域、事件总线、过度抽象 | 失败开始影响真实客户 |
| 稳定增长 | 性能与流程哪里真的受限 | 针对瓶颈加缓存、队列、监控 | 因“以后可能”整体重写 | 指标显示明确瓶颈 |
| 收缩或退出 | 什么仍值得维护 | 导出、迁移、降级、关闭流程 | 用新功能掩盖留存问题 | 收入、使用或战略不再成立 |
这个表最重要的一列是“暂时不做”。独立开发不是资源少的公司开发，而是注意力不能被会议和同事补回来的开发。
三、数据库与 API：把边界留在自己手里
数据库先选关系型
大多数订阅产品、工具和内容型应用，最初都适合从 PostgreSQL 或 MySQL 开始。用户、订单、权限和状态流转天然需要约束与事务。只有访问模式已经明确、关系模型确实不合适时，我才会引入文档库、向量库或时序库。
建表时先守住几件小事：
- 每张业务表有稳定主键、创建时间和更新时间；
- 金额使用最小货币单位的整数或明确精度的十进制，不用浮点数；
- 关键状态用约束或受控枚举，不把任意字符串当状态机；
- 唯一性、外键和权限尽量由数据库执行，不只靠界面约定；
- Schema 变更进入版本控制，迁移可向前执行，也写清回滚或修复办法；
- 定期做导出，并实际演练恢复；“有备份”不等于“能恢复”。
Supabase 的稳定边界是以 PostgreSQL 为核心，组合认证、存储、实时能力等托管服务；它能减少拼装工作，但行级权限、密钥隔离、迁移和备份仍是开发者的责任。PlanetScale 是托管关系数据库平台，提供 Vitess 与 PostgreSQL 产品；Vitess 路线与 MySQL 兼容，但并不等于本地 MySQL 的每个特性都可原样使用，迁移前应逐条查看其兼容性限制 。
我不会因为“未来可能很大”就一开始选择分布式数据库。先问更现实的问题：能否导出标准格式？本地能否复现？连接层是否绑定专有 SDK？迁移时要重写多少查询和权限逻辑？
API 先写契约，不先写框架
内部 API 也应该有清楚的输入、输出、错误和权限边界。REST 足以覆盖多数 MVP；GraphQL、RPC 或事件驱动架构应由真实的客户端组合需求、吞吐或异步流程推动。
一个创建资源的接口，至少要决定：
- 谁能调用，身份来自哪里；
- 输入如何校验，未知字段如何处理；
- 重试会不会生成重复数据；
- 成功、业务冲突和系统失败分别返回什么；
- 日志里记录哪个请求 ID，哪些敏感字段必须遮蔽；
- 客户端升级时，旧契约保留多久。
支付回调、邮件任务和第三方 webhook 必须按“会重复、会延迟、会乱序”设计。用事件 ID 或业务唯一键做幂等，比在事故后人工删重复订单便宜得多。
四、Git、Docker 与 CI：把个人记忆写进系统
Git 对独立开发者的价值不是协作人数，而是让每次修改可解释、可撤销。我倾向于小提交：一个提交只表达一个意图，提交说明写“为什么”，功能分支尽量短。密钥永远不进入仓库；.env.example 只保留变量名与安全示例。
Docker 不是 MVP 的入场券。若托管平台能从仓库稳定构建，且本地与线上运行时一致，可以暂时不写容器。出现以下情况时再引入：
- 应用依赖系统库或多个进程；
- 团队或 CI 经常遇到“我的机器可以”；
- 需要在不同宿主间迁移；
- 后台任务或自托管服务需要一致的运行环境。
容器镜像应固定基础版本、使用非 root 用户、设置健康检查，并把状态放到外部数据库或对象存储。不要把数据库文件留在随时可能被替换的应用容器里。
最小 CI 只需要在每次合并前自动执行：
格式与静态检查 → 单元/集成测试 → 构建 → 数据库迁移检查
部署可以在主分支通过后自动触发，但生产数据库迁移和不可逆操作应保留闸门。CI 的目的不是展示流程图，而是阻止疲惫时的我把已知错误送给用户。
五、测试：保护最贵的失败
“MVP 不需要测试”通常把测试误解成追求覆盖率。独立产品真正需要的是按风险分配测试：
- 纯业务规则用单元测试，例如价格、权限、状态转换；
- 数据库查询、认证和第三方适配器用集成测试；
- 注册、核心任务、付款与取消等少数关键旅程用端到端测试；
- 不能稳定自动化的流程，保留发布前人工检查表。
Cypress 可以用于浏览器端到端测试，但工具不是重点。Playwright 或其他框架同样可行；真正的边界是端到端测试更慢、更容易受环境影响，因此只覆盖会直接破坏收入或信任的路径。
我给 MVP 的最低发布线是：
- 新用户能完成核心结果；
- 权限测试证明用户看不到别人的数据；
- 支付或配额逻辑能安全重试；
- 数据库迁移在临时环境跑过；
- 错误会被记录，并能关联到请求；
- 上一版本有明确回退办法。
覆盖率可以提示盲区，却不能证明产品可靠。十个只验证实现细节的测试，不如一个验证“重复 webhook 不会重复扣款”的测试。
六、部署、支付与分析：托管的是工作，不是责任
部署
Vercel 适合与其支持的 Web 框架和函数运行时结合，Cloudflare Pages 与 Workers 更靠近静态资产与边缘运行模型。两者都能缩短首次上线时间，但都存在运行时、执行时长、包体、区域和计划相关限制；不要把传统常驻进程未经验证地塞进函数环境，也不要假设计算节点天然靠近数据库。
我的部署清单比平台选择更稳定：
- 开发、预发布和生产环境分离；
- 域名、TLS、密钥轮换和最小权限有负责人——通常就是我；
- 数据库与计算尽量同区域，跨境与数据驻留要求单独评估；
- 结构化日志包含请求 ID，但不记录密码、令牌和完整支付信息；
- 有正常运行探针、错误告警、备份与恢复演练；
- 知道如何导出数据并在另一台机器启动。
支付
支付不是“接一个按钮”，而是订单、权益、退款、税务、争议与对账组成的状态机。先确定目标市场、经营主体、结算地区与税务责任，再选择支付服务。
Stripe 一类支付处理商和 Lemon Squeezy 一类 Merchant of Record 的责任边界不同。后者可承担记录商户范围内的税务与交易职责，但不代表开发者在所有司法辖区都没有申报、消费者保护或隐私义务。可用国家、支付方式、费率和审核规则会变化，集成当天以官方条款为准。
本地数据库不要把前端“支付成功”当真相。以服务端校验过的 webhook 更新权益，保存外部事件 ID 与原始状态，处理重复和乱序，并提供人工对账入口。
分析
分析只收集会改变决策的数据。MVP 通常只需要四类事件：
- 访问者是否到达价值页面；
- 是否开始并完成核心任务；
- 在哪一步失败或离开；
- 是否再次回来并付费。
Umami 的产品设计强调无 Cookie 和减少个人数据收集，但这不能推出“任何地区、任何配置下都无需同意横幅”。自定义事件内容、IP 处理、托管位置、与其他数据的组合方式，以及你面向的司法辖区，都会改变合规判断。隐私声明应准确描述实际采集，必要时咨询专业人士。
不要为了“以后分析”记录所有点击。采集越多，解释成本、隐私责任和噪声也越多。
七、维护与退出成本：上线之后才开始计息
每引入一个服务，我都会补一张很短的依赖卡：
| 问题 | 必须写下的答案 |
|---|---|
| 它替我承担什么？ | 数据库、身份、构建、支付还是观测 |
| 数据在哪里？ | 区域、格式、保留周期、备份方式 |
| 如何离开？ | 导出命令、替代方案、预计重写范围 |
| 失败会怎样？ | 用户影响、降级策略、人工处理入口 |
| 谁能访问？ | 密钥位置、权限范围、轮换办法 |
| 何时复查？ | 触发指标或固定复盘日期 |
退出成本不是“绝不使用 SaaS”。恰恰相反，我愿意用钱购买暂时不擅长的能力，但不会把可迁移性留给未来的自己。标准 SQL、普通对象格式、清楚的适配层和定期导出，都是廉价的退路。
维护时，我每月只看几组能行动的信号：激活、留存、付费、错误、恢复时间和单用户服务成本。若一个功能没人使用，就删除；若人工处理持续增长，就自动化；若基础设施费用增长但用户价值没有增长，就先查设计，再升级套餐。
关闭产品也应该被设计：提前通知、停止续费、提供数据导出、处理退款与法定义务、保留必要记录，然后撤销密钥和删除不再需要的数据。一个产品能体面地结束，才算真正拥有过自己的系统。
八、我会怎样从零再做一次
如果今天重新开始，我会按下面的顺序：
- 用一页纸写清用户、场景、现有替代和最危险假设；
- 访谈真实用户，用手工服务交付一次结果；
- 做一个只有核心闭环的单体应用，使用我最熟悉的语言；
- 选择一个关系数据库，先写约束、迁移和导出；
- 用 Git 保存小步变化，在 CI 里跑检查、测试与构建；
- 只给核心旅程补端到端测试，上线预发布环境；
- 接入服务端验证的支付与最小事件分析；
- 为日志、告警、备份、恢复和退出路径各做一次演练；
- 根据用户行为决定下一项工作，而不是根据技术新闻。
AI 可以替我生成脚手架、测试草稿和迁移方案，但不能替我确认用户是否真的痛，也不能替我承担生产权限。生成的代码仍要经过契约、测试、依赖和安全审查。速度的意义是更快拿到证据，不是更快堆积无法解释的代码。
结语：技术栈是一组承诺
选择数据库，是承诺怎样保存别人的数据；选择支付，是承诺怎样处理金钱和权益；选择部署平台，是承诺故障时如何恢复；选择分析工具，是承诺不因为好奇而过度收集。
所以我的技术栈不会从“哪个最强”开始，而从三个问题开始：
现在最危险的未知是什么？
最小的验证闭环是什么？
如果判断错了，我能否低成本离开？
独立开发的自由，不是可以使用所有工具，而是知道哪些承诺此刻还不必做。把复杂度留到证据出现以后，把退路留在设计里面，然后尽早把一个真实结果交到用户手里。
读者回响