一个人做 SaaS 出海：从找需求到第一笔美元，7 步跑通闭环

AI 让一个人做产品成为可能。

过去需要产品、设计、开发和运营协作几个月的项目，现在一个人借助 AI，也许几周就能做出可用版本。但开发效率提高，不等于产品自然有人买。

真正决定 SaaS 能不能跑起来的，仍然是三个问题：

产品：你解决的是不是真实且高频的问题？
流量：目标用户能不能持续找到你？
变现：用户是否愿意付费，支付和交付能否顺利完成？

这也是我从《一人 AI 公司出海蓝皮书》中提炼出的核心框架：

一个人的价值，不是亲手完成所有工作，而是找到正确需求、组合现有能力，并持续完成”发现—上线—验证—迭代”的闭环。

下面按 7 个步骤展开。

一、先判断：你为什么要出海？

出海不是国内做不起来之后的”换地图重试”。

如果产品价值没有成立，把界面翻译成英文、换一台海外服务器，并不会自动带来用户。相反，你还会增加语言、支付、客服、合规和获客等变量。

开始之前，先回答三个问题。

1. 产品价值是否已经得到初步验证？

不一定要先在国内做大，但至少要有一种有效证据：

有人主动使用，而不是只说”这个想法不错”；
有人愿意付费，或者愿意留下邮箱等待上线；
用户会重复使用，而不是体验一次就离开；
你能明确说出产品替用户省了什么：时间、成本、风险还是专业门槛。

2. 你能否长期服务目标市场？

英文不需要像母语者一样流利，但产品文案、帮助文档和客服回复必须清楚。AI 可以帮助润色，却不能替你理解用户真正的问题。

如果准备进入日本、欧洲或中东等市场，还要考虑本地语言、支付习惯和文化差异。不要只看”哪个市场更大”，更要看你在哪个市场拥有信息、语言或渠道优势。

3. 你是否接受一段时间没有收入？

出海往往意味着从零建立信任。域名、产品和支付都准备好之后，仍可能几个月没有稳定收入。

因此，启动标准不应是”我能不能做出来”，而应是：

即使短期没有收入，我是否仍愿意连续迭代 8—12 周？

二、选需求：用数据代替拍脑袋

蓝皮书里最值得保留的方法，是把选品拆成两个问题：

第一个问题：这个需求”该不该做”？

先判断市场，而不是先写代码。

可以从四类信号入手：

搜索需求：用户是否正在搜索相关问题？趋势是增长、稳定还是下降？
竞争结构：搜索结果前排是大而全的平台，还是已经出现多个高度专注的垂直产品？
付费证据：竞品是否明确收费？用户是否在评价区讨论价格、替代方案和购买体验？
获客路径：用户会通过 Google、社交媒体、应用市场、社区还是销售触达找到产品？

搜索量高不等于适合进入。如果首页全部是强大的垂直产品，你面对的可能不是”有需求”，而是”需求已经被充分满足”。

反过来，如果排名靠前的只是大网站里一篇浅层文章，而用户真正需要的是一个专门工具，独立开发者反而可能有机会。

第二个问题：这个需求”能不能做”？

AI 时代的正确问题，不是”我能不能从零开发全部技术”，而是：

有没有成熟 API、开源组件或基础设施，能让我低成本地交付结果？

评估时至少列出：

核心 API 的效果、速度、稳定性和单次成本；
开源项目的许可证是否允许商用；
每个用户使用一次产品的边际成本；
数据、模型和第三方服务是否存在地区限制；
如果某个供应商涨价或停服，是否有替代方案。

建议为每个候选方向做一张”机会卡”：

项目	需要回答的问题
目标用户	谁最痛？谁有预算？
使用场景	用户在什么时刻需要它？
现有替代方案	用户现在怎么解决？
获客渠道	用户会在哪里搜索或讨论？
交付成本	API、服务器和人工支持成本是多少？
差异化	为什么选择你，而不是现有产品？

只有”该做”和”能做”同时成立，才值得进入开发阶段。

三、产品形态：先做 Web MVP，再考虑 App

对资源有限的独立开发者，Web 通常是更合理的第一站。

原因很直接：

用户点击链接即可体验，路径短；
不需要等待应用商店审核；
修复问题后可以立即发布；
一套产品即可覆盖桌面端和移动浏览器；
域名、托管和分析工具的启动成本较低。

这并不意味着 App 没有价值。涉及高频使用、系统能力、离线体验或推送通知时，App 可能更合适。但在需求尚未验证时，先做 Web 能显著降低试错成本。

MVP 只需要跑通一条核心路径

不要在第一版里同时做十个功能。先保证用户能够：

看懂产品解决什么问题；
输入必要的信息；
获得一次有价值的结果；
知道免费与付费的区别；
完成注册或付款；
在遇到问题时找到你。

技术栈不是重点。Vercel、Cloudflare、Railway 等都能帮助快速上线，但要注意具体套餐限制：例如 Vercel Hobby 主要面向非商业个人项目，Railway 的试用额度也不等于长期免费。

你的目标不是搭建”最先进的架构”，而是在 1—2 周内获得第一批真实反馈。

四、变现：先设计商业模式，再接支付

蓝皮书把常见网站变现分为广告、订阅和联盟营销。对 SaaS 来说，核心通常是订阅或按量付费，另外两种更适合特定场景。

1. 订阅或按量付费

适合持续提供价值的产品，例如分析、自动化、内容生成、团队协作和专业工具。

常见组合包括：

免费试用 + 月付/年付；
免费版 + 专业版；
按使用次数购买额度；
个人版 + 团队版；
自助套餐 + 企业定制。

不要只比较”9 美元还是 19 美元”。更重要的是让用户清楚：付费后能节省多少时间、得到什么结果、解除什么限制。

2. 广告

适合高流量、低付费意愿的免费工具或内容站。它依赖大量访问和广告展示，不适合流量很小但计算成本很高的 AI 产品。

3. 联盟营销

适合评测、导航和行业内容产品。前提是推荐与用户需求高度相关，并清楚披露利益关系。

支付工具怎么选？

Stripe：生态成熟，适合符合支持地区和主体要求的商家；费率因地区、卡种和跨境交易而异。
Lemon Squeezy / Paddle：采用 Merchant of Record 模式，可代为处理支付及部分销售税事务，基础费率通常高于直接支付服务，开户仍需审核。
PayPal：覆盖广，可作为补充方式，但结账体验、争议处理和跨境费用需要单独评估。

不要等产品完成后才研究支付。主体、地区、业务类型和提现路径，应在开发前确认。

同时要注意：Merchant of Record 能减轻部分间接税处理负担，但不等于替你解决公司所得税、个人税务、外汇和全部合规问题。

五、流量：建立资产，而不是只追求一次曝光

产品与流量必须同时设计。

如果产品上线后才开始想”去哪里找用户”，往往已经晚了。选需求时就应该知道，用户会通过什么渠道找到你。

1. SEO：长期积累的数字资产

SEO 的本质不是堆关键词，而是为一个明确问题提供更好的答案。

一个合格的产品页面至少要做到：

Title 和 H1 清楚描述核心用途；
首屏直接说明用户能得到什么结果；
展示真实使用步骤、示例和限制；
用 FAQ 回答价格、隐私、数据和退款问题；
页面速度快，移动端可正常使用；
提交 Sitemap，并接入 Search Console；
围绕真实长尾需求持续建设内容。

不要机械追求关键词密度，也不要批量制造低质量外链。搜索流量是长期资产，但前提是页面真正解决用户问题。

2. 社区与公开构建

在 X、Reddit、Indie Hackers 或垂直社区中分享开发过程、数据变化和真实教训，比反复发送产品广告更容易建立信任。

原则是先提供价值，再自然介绍产品。每个社区都有自己的规则，发布前先观察和参与。

3. 定向触达

如果目标用户非常明确，可以寻找 20—50 个潜在用户，发送简短、个性化的邮件或私信。

目标不是立刻成交，而是验证：

对方是否承认这个问题存在；
目前如何解决；
为什么愿意或不愿意尝试你的产品；
哪种结果值得付费。

4. Product Hunt 等发布平台

它们适合制造一次集中曝光和获得早期反馈，但不能替代持续获客渠道。发布只是一次事件，SEO、社区和用户推荐才是长期系统。

在自然流量尚未验证、落地页转化路径尚不清楚之前，不建议急着投放广告。

六、合规：最低限度也要建立清楚的边界

出海产品至少要准备：

Privacy Policy；
Terms of Service；
联系方式和退款说明；
用户数据导出、删除或注销机制；
第三方分析、支付和 AI 服务的披露；
必要时的 Cookie 同意机制。

如果产品处理健康、金融、儿童、身份信息或其他敏感数据，要求会明显提高。

使用 AI API 时，要向用户解释：

哪些数据会发送给模型服务商；
数据用于什么目的；
保存多长时间；
用户如何要求删除；
AI 输出可能存在什么限制。

不同地区的隐私、消费者保护、AI 和税务规则不同。模板只能帮助起步，不能替代针对具体业务的专业审查。

七、迭代：用数据完成最后一个闭环

上线不是结束，而是第一次获得真实信息。

蓝皮书里有一个很实用的区分：

定量数据告诉你”发生了什么”；
定性信息告诉你”为什么发生”。

定量数据关注什么？

早期 SaaS 不需要几十个指标，先看：

访问来源；
首次核心动作完成率；
注册转化率；
试用到付费转化率；
次日、7 日或月度留存；
退款和流失原因；
单个用户的服务成本。

定性信息从哪里来？

用户访谈和客服邮件；
取消订阅时的原因；
会话录屏和热力图；
用户在输入、生成、付款等步骤的卡点；
用户主动要求但产品尚未提供的功能。

可以用 Google Analytics、PostHog 或 Plausible 做定量分析，用 Microsoft Clarity 观察热力图和会话行为。工具不是越多越好，关键是形成固定节奏：

每周找出一个最大流失点，提出一个假设，完成一次改动，再观察数据是否改善。

这才是真正的数据驱动，而不是每天刷新访问量。

一份可执行的 30 天计划

第 1—3 天：筛选方向

列出 3 个候选需求；
检查搜索、竞品和付费证据；
完成”该不该做”和”能不能做”的判断。

第 4—7 天：验证问题

找 10 个目标用户交流；
做一个简单落地页；
收集邮箱、预约或预售意愿。

第 8—14 天：完成 Web MVP

只实现一条核心路径；
接入最必要的 API；
部署产品并处理基础错误监控。

第 15—18 天：打通商业闭环

确认支付平台可开户；
完成定价和结账；
补齐隐私政策、服务条款和退款说明。

第 19—21 天：小范围发布

邀请第一批用户；
接入定量和定性分析；
记录所有卡点，不急着扩功能。

第 22—30 天：获取流量并迭代

发布 2—3 篇针对长尾问题的内容；
在一个垂直社区持续参与；
定向联系一批潜在用户；
根据数据修复最大的转化问题。

最后几句实话

第一，AI 降低的是实现成本，不是商业难度。写出代码，只是拿到入场券。

第二，一个人公司的核心能力不是”什么都会”，而是知道什么最重要，并善于调用 AI、API、开源项目和外部服务。

第三，流量不是产品完成后的附加题。需求、关键词、渠道和产品形态应该一起设计。

第四，不要同时做太多项目。持续完成一个小闭环，比收集几十个想法更有价值。

第五，第一笔美元的重要性不在金额，而在于它证明了一件事：你发现了一个真实需求，并完成了从产品到交付的完整链路。

如果你正在考虑做 SaaS 出海，可以先从一张机会卡和一个 Web MVP 开始。

不要等一切准备完美。先让一个真实用户用起来，再根据事实决定下一步。

— 彦华