SaaS
把一项重复性的工作变成按月订阅的在线服务。
谁在付钱
能独立完成前后端开发的程序员，希望获得可预测的月度经常性收入。
怎么收钱
按月/按年订阅 · 按席位计费 · 分级定价（免费版 + 付费版）
业务模式
同样是出海，卖 SaaS、卖 API、卖数字产品的路径并不相同。选一个最接近你手上资源的模式看下去——这里解释「这门生意怎么运转」，技术栈在另一边。
AI 产品
以模型能力为核心的产品，卖的是「把模型变成可交付结果」的那一层。
谁在付钱
熟悉 API 调用与产品化的开发者，能在模型之上做出稳定的工作流。
怎么收钱
订阅 + 用量上限 · 按次/按量计费 · 积分包
App
面向手机端的应用，通过应用内购买或订阅变现。
谁在付钱
熟悉移动端开发的独立开发者。
怎么收钱
应用内订阅 · 一次性买断 · 应用内购买（消耗型）
API / 模型
把一项能力封装成接口，按调用量出售。
谁在付钱
有明确技术能力、能定义清楚接口边界的开发者。
怎么收钱
按调用次数计费 · 阶梯用量定价 · 额度包
数字产品
模板、课程、素材、工具包等一次制作、多次销售的产物。
谁在付钱
具备某项专业技能、希望低成本验证变现的开发者或创作者。
怎么收钱
一次性买断 · 捆绑包 · 会员订阅
跨境电商
把实体或虚拟商品卖到海外市场。
谁在付钱
有供应链或选品能力，能处理物流与售后的团队。
怎么收钱
商品零售差价 · 订阅式补货 · 捆绑销售
业务模式页面解释这门生意怎么运作；技术栈页面解释运营它需要哪些基础设施。两者不重复。
先用两个问题缩小范围
每个模式卡片上都写着「谁在付钱」和「怎么收钱」。这两栏不是装饰，是筛掉不合适选项最快的方式。付钱的人如果是个人用户，你的定价、退款和客服预期与企业客户完全不同；收钱方式如果是一次性买断，你就不需要先搭订阅与续费体系。
先回答这两问，再看模式页面里的成本类别和获客渠道。顺序反过来，容易变成先挑一个听起来大的市场，再回头硬凑收钱方式。
模式页面里的「从想法到收入」六个节点，标了每个节点必须做什么、可以推迟什么。选模式时可以先只读这两栏：如果某个模式的「必须做」里有一项你现在完全没有条件完成，那它就不是当下的选项。
同一件事可以按不同模式卖
一套模板可以当数字产品一次性卖掉，也可以做成订阅库按月收费；一项能力可以封装成有界面的产品，也可以按调用量卖接口。区别不在技术实现，而在你承诺了什么：订阅意味着持续服务和维护义务，一次性买断意味着交付完成即结束，售后仍然存在。
判断依据可以很具体。用户的需求是「一次做完」，订阅会让他觉得被长期收费；需求是「持续产生结果」，一次性买断会让你的成本随着使用不断累积。先看需求形态，再选收钱方式。
模式可以共存，但别同时开始
- 一个人真正稀缺的是注意力。同时推两种模式，常见的结果是两个都没验证完。
- 先选一个能在最短路径上收到钱的模式，把付费意愿验证出来，另一个写成文档放着。
- 已经选定的模式，前三个月不要因为看到另一个模式热闹就换。换模式的成本主要落在你已经积累的素材和渠道上。
- 两种模式如果面向同一批用户，先做哪一个都可以，但不要同时向同一批人收两种钱，定价页会变得很难解释。
- 业务天然需要两种模式时（例如工具免费、服务收费），先明确哪一个是收入来源，另一个负责获客还是留存。
常见问题
我能不能同时做两种模式？
可以共存，但别同时开始。两种模式的技术栈与收款结构往往不兼容，同时推进会让两边都做不深。更常见的做法是先跑通一种、拿到第一笔收入，再考虑用同一批能力延伸第二种。
选错模式会怎样？
最大的代价不是时间，而是收款结构。主体类型、支付通道与定价方式一旦被早期用户接受，改动的成本很高——可能需要重新签约、重新告知客户。所以模式判断值得花几天想清楚。
模式定了之后还能改吗？
能，但要付迁移成本。产品形态可以从一次性交付转成订阅，也可以从订阅转成按用量计费，前提是提前在数据模型与账单结构上留出空间。完全没有留余地的架构，改起来接近重做。
没有收入之前，需要先确定模式吗？
需要，但不需要确定所有细节。模式决定的是「你靠什么收钱」和「谁是你的付费方」，这两个问题会影响主体、收款与技术选型。越晚确定，前面这些决策越可能需要重做。