开头
很多独立开发者在开始做产品时，第一反应是先找一套“完整技术栈”。
前端用什么，后端用什么，数据库选什么，AI 接口怎么接，邮件怎么发，支付怎么收，监控怎么做。问题看起来都很技术，最后也很容易变成一张工具清单。
但我现在越来越觉得，早期真正要解决的不是“技术栈是否先进”，而是另一件事：
一个想法能不能以足够低的成本，被真实用户看到、理解、提交需求、完成交付，并留下下一次迭代的证据。
所以我不会把这篇写成“某某工具推荐大全”。工具会变，免费额度会变，平台政策会变。真正值得沉淀的是一套搭建顺序和判断原则。
对独立开发者来说，第一套基础设施应该服务于一个目标：
先把业务路径跑通，再决定要不要把技术做重。
第一原则：早期产品缺的不是架构，而是路径
很多产品还没有用户、没有订单、没有稳定内容来源，就已经在纠结微服务、权限系统、复杂数据库、容器编排和多环境发布。
这些东西不是没价值，而是阶段不对。
早期产品最脆弱的地方通常不是技术，而是：
- 用户不知道你是谁。
- 用户看不懂你解决什么问题。
- 用户不知道下一步该点哪里。
- 你不知道谁真的有需求。
- 有人提交需求后，你不知道怎么跟进。
- 有人愿意付费时，你还没有清楚的收款和交付边界。
- 页面挂了、表单坏了、邮件没到，你自己也不知道。
所以第一套基础设施不应该围绕“系统多完整”来搭，而应该围绕“业务能不能闭环”来搭。
我会把它拆成七个问题：
- 用户从哪里看见你？
- 用户在哪个页面理解你？
- 用户如何留下需求？
- 你如何处理这条需求？
- 你如何通知和跟进？
- 用户如何付款或预约？
- 你如何发现系统出问题？
这七个问题，比“用什么框架”更接近产品真实生命线。
第一层：公开入口，先让产品被访问
独立开发者最先需要的是一个公开入口。
它可以是个人主页、产品页、资源页、工具页、诊断表单，也可以是一个非常简单的专题页。重点不是页面多漂亮，而是用户打开后能快速判断三件事：
- 这里适不适合我。
- 我能拿到什么。
- 下一步怎么做。
这一层，我现在更倾向于用静态站优先。
原因很简单：静态站足够快、足够稳定、部署成本低，也更适合一个人长期维护。像我的几个站点，首页、Starter、Risk Lab，本质上都是先用静态页面承接不同意图。
推荐顺序是：
- 静态内容和专题页：Cloudflare Pages。
- React / Vite 小应用：仍然可以走 Cloudflare Pages。
- 重度 Next.js 项目：可以考虑 Vercel。
- 博客和知识库：看内容系统习惯，可以是 NotionNext，也可以是独立静态站。
这里有一个很重要的细节：
如果用 Cloudflare Pages 部署前端路由，一定要配置
_redirects。否则
/payment-path、/lab、/resources 这种路径在本地正常，上线后刷新或直接访问就可能回首页或 404。这个坑我刚刚在 Starter 和其它站点里补过。所以公开入口的最低配置不是“能打开首页”就够，而是：
- 首页能打开。
- 专题页能直接访问。
- 分享链接能打开。
- 刷新后不丢页面。
- 错误路径有合理兜底。
这比一开始做很复杂的后台更重要。
第二层：表单和轻后端，先接住真实需求
有了页面以后，下一步不是马上做复杂会员系统，而是先让用户能表达需求。
早期最有价值的数据不是浏览量，而是用户愿意主动告诉你：
- 我是谁。
- 我遇到什么问题。
- 我现在卡在哪里。
- 我希望得到什么帮助。
- 我是否愿意继续了解或预约。
这就是表单和轻后端的价值。
我的默认选择是：
- 简单表单：先用 Pages Functions 或 Cloudflare Workers 接住。
- 轻量 API：优先 Workers。
- 数据暂存：D1、KV、Notion、Google Sheet 都可以按阶段选择。
- 复杂账号系统：不要太早做，除非产品本身必须登录。
Workers 很适合独立开发者，因为它解决的是“轻后端”问题：表单提交、AI 转发、邮件通知、Webhook、简单权限校验、限流和缓存。
它不是传统服务器思路，也不适合一开始就写成复杂后端。但对早期产品来说，它刚好够用。
我现在会把后端分成三档：
第一档：不需要账号，只需要提交需求
适合资源领取页、诊断表单、候补名单、咨询预约。
这个阶段不用急着上数据库，可以先写入 Notion、发送邮件，或者保存到一个简单数据表。
目标是确认有没有人愿意认真填写。
第二档：需要保存用户状态
适合工具实验室、成本测算器、清单进度、轻量仪表盘。
这个阶段可以考虑 D1、KV、Supabase。
目标是让用户下次回来还能继续，而不是每次都从头开始。
第三档：需要账号、权限、支付和长期数据
适合 SaaS、会员工具、私人工作台、客户后台。
这个阶段再考虑 Supabase Auth、Postgres、RLS、文件存储、支付状态和更完整的数据模型。
不要把第三档的复杂度提前搬到第一档。
第三层：数据存储，不要一开始就追求“最终形态”
数据库选型最容易让人过度设计。
早期真正要问的是：
- 这份数据会不会频繁查询？
- 数据结构是否稳定？
- 是否需要用户权限？
- 是否需要文件存储？
- 是否需要迁移到长期系统？
如果只是候补、诊断、资源申请，Notion 或 Sheet 可能已经够用。因为它们更适合人工跟进，也更适合一个人边看边判断。
如果是页面配置、轻量状态、缓存结果，KV 很合适。
如果是结构化业务数据，D1 或 Supabase 更合适。
如果未来要做完整产品，Postgres 的长期价值更高。
我的原则是：
早期数据先服务判断，后期数据再服务系统。
不要为了未来可能出现的复杂需求，把今天的验证速度拖慢。
第四层：AI 接口必须加一层自己的网关
现在做 AI 产品，最容易犯的错误是直接在前端调用模型接口。
这件事不能做。
AI Key 一旦暴露，就不是成本问题，而是风险问题。别人可以盗刷，可以绕过你的产品逻辑，也可以让你无法判断真实使用情况。
所以无论模型用哪家，至少要加一层自己的网关：
- Key 放在服务端环境变量。
- 前端只请求自己的 API。
- 服务端做基础限流。
- 相同请求做缓存。
- 对异常请求做拦截。
- 记录必要的使用量。
这层网关可以很薄，Workers 就够。
对我的项目来说，这层能力会越来越重要。Starter 里的 AI 工具实验室、Risk Lab 的成本测算、未来的内容生成工具，都需要这层统一能力。
我不追求一开始就做完整 AI 平台，但至少要把下面这些事想清楚：
- 每次调用大概多少钱。
- 免费用户能调用多少次。
- 重复请求能不能缓存。
- 输出失败时如何提示用户。
- 是否需要人工兜底。
- 哪些请求不应该发给模型。
AI 的成本已经比过去低很多，但低成本不等于可以无脑调用。
第五层：邮件和通知，是业务闭环的一部分
很多人会低估邮件。
页面做完了，表单能提交了，但用户提交后没有收到确认，你自己也没有收到提醒，这条需求就很容易断掉。
早期产品不一定需要复杂 CRM，但至少要有三类通知：
- 用户提交后，知道自己已经提交成功。
- 你自己收到提醒，知道有人需要跟进。
- 后续资源开放、诊断确认或交付更新时，能通知对方。
邮件服务可以用 Resend、Brevo 等成熟服务，不建议一开始自建 SMTP。
邮件不是技术装饰，而是信任体验的一部分。
如果用户填完表单后什么都没有发生，他会怀疑这个站是不是没人维护。
第六层：支付不要孤立判断，要和交付边界一起设计
支付是独立开发者迟早要面对的问题，但它不能单独看。
不能只问“用 Stripe 还是 PayPal”，更要问：
- 你卖的是什么？
- 是数字文件、咨询、模板、课程、会员，还是定制服务？
- 用户在哪个国家或地区？
- 是否需要退款？
- 是否需要发票？
- 交付发生在付款前还是付款后？
- 出问题时谁处理争议？
这也是我为什么在 Starter 里单独拆出“收款路径”页面。
支付工具只是最后一环，前面还要有页面说明、产品边界、退款规则、交付证明和联系方式。
如果没有这些，支付开通了也不代表业务跑通。
对早期项目来说，可以分三条路径判断：
国内轻量收款
适合中文客户、咨询、小额服务、模板售卖。
重点是主体、合规、退款和沟通边界。
国际 MoR 平台
如 Lemon Squeezy / Paddle 这类 Merchant of Record，适合没有海外主体但想先卖数字产品的人。
优点是启动快，缺点是费率和平台规则要接受。
Stripe / PayPal 等长期路径
适合已经有更明确海外业务、主体和长期收款需求的人。
这条路更正规，但准备成本也更高。
不要为了显得国际化，一开始就把自己卡在最重的路径里。
第七层：监控和复盘，让你知道哪里坏了
早期产品不需要一堆复杂看板，但至少要知道三件事：
- 页面是否能访问。
- 表单是否能提交。
- 关键 API 是否报错。
最低配置可以是：
- UptimeRobot / Better Stack：监控可用性。
- Sentry：监控前端和后端错误。
- Cloudflare 日志 / Pages 部署记录：看部署和访问异常。
- 简单事件记录：看用户点击和提交路径。
监控不是为了显得专业，而是为了避免“用户已经出问题了，你还不知道”。
这对一个人做项目尤其重要，因为你没有客服团队、运维团队、测试团队，所有问题最后都会回到你自己身上。
我的默认组合
如果今天我要从 0 开一个独立小产品，我会这样搭：
第一版：验证想法
- 页面：Cloudflare Pages。
- 路由：配置
_redirects，保证专题页可直接访问。
- 表单：Workers 或 Pages Functions。
- 数据：Notion / Sheet / 邮件通知。
- 邮件：Resend。
- 监控：UptimeRobot。
- 支付：先人工确认或候补，不急着自动化。
目标：确认有没有人看得懂、愿意填、愿意继续了解。
第二版：可交付产品
- 页面：继续 Pages，增加专题页和资源页。
- 后端：Workers 做 API、AI 转发、限流。
- 数据：D1 / KV 存轻量状态。
- AI：统一走自己的网关。
- 邮件：提交确认、候补通知、交付提醒。
- 支付：按产品形态接入合适路径。
目标：让用户可以完成一次真实购买、预约或交付。
第三版：长期产品
- 数据：Postgres / Supabase。
- 账号：只在确实需要时加入 Auth。
- 文件：R2 或对象存储。
- 监控：Sentry + 可用性 + 关键业务事件。
- 支付：自动化订单状态、退款规则和交付记录。
目标：减少人工处理，开始沉淀可持续系统。
不要省错地方
低成本不是所有东西都免费。
有些钱应该花：
- 域名应该买一个长期能用的。
- 关键邮件应该用可靠服务。
- 支付路径要考虑合规和信任。
- 监控不能完全没有。
- 重要数据要有备份。
真正不该花的是：
- 在没有用户前买很重的服务器。
- 在没有订单前做复杂后台。
- 在没有清晰产品前接一堆第三方系统。
- 在没有使用量前过度优化架构。
- 在没有验证前追求“看起来像大公司”。
独立开发者最贵的资源不是服务器，而是注意力和时间。
第一套基础设施应该帮你减少分心，而不是制造更多维护负担。
结论
独立开发者的低成本技术栈，本质上不是“省钱清单”，而是一套阶段判断。
第一阶段，先让用户看见你。
第二阶段，让用户能表达需求。
第三阶段，让你能处理需求。
第四阶段，让用户能付款或预约。
第五阶段，让系统出问题时你能知道。
等这些都跑通以后，再升级数据库、账号系统、支付自动化、客户后台和更复杂的 AI 能力。
如果一开始就追求完整系统，很容易把自己拖进无穷无尽的技术细节里。
如果一开始只搭一条足够轻的业务路径，就更容易在真实反馈里迭代。
我的判断是：
独立开发者第一套基础设施，不是为了证明自己技术强，而是为了让第一个产品尽快进入真实世界。
技术的价值，不是堆满组件，而是让想法能被看见、被使用、被付款、被复盘。
Loading...
