很多独立开发者并不是先有一个完整的 SaaS 产品，再自然获得订阅收入。更常见的路径是：先靠项目、作品或一次性销售获得现金流，再逐步发现哪些需求值得标准化，最后把收入从“交付一次、收款一次”改造成“持续提供价值、持续续费”。
Pieter Levels 的经历适合用来观察这条路径，但需要先说明一个边界：他并不是典型的“接外包多年后，把某个客户项目改造成 SaaS”。他的公开创业经历更接近于从一次性产品、独立项目和临时性收入，逐步转向会员订阅、职位发布和其他可重复收费的产品模式。因此，本文不会把他包装成标准答案，而是把他当作一个收入模式转型的参照案例。
这个案例到底发生了什么
Pieter Levels 是公开记录较多的独立开发者。他没有从融资、组建大团队或承接大型企业项目开始，而是持续制作小型互联网产品，并公开分享开发、发布和经营过程。
其中较有代表性的产品包括 Nomad List 和 Remote OK。前者围绕数字游民的城市信息、生活成本和社区服务展开，后者面向远程工作机会。两类产品的共同点是：用户不是购买一次软件安装包，而是为了持续访问数据、社区或职位信息付费。
这意味着收入逻辑发生了变化：
- 一次性项目依赖不断寻找新客户；
- 标准化产品依赖持续解决一类用户问题；
- 订阅收入依赖用户留下来，而不是只依赖第一次付款；
- 产品价值不再主要来自开发者投入了多少工时，而来自用户是否持续需要它。
公开资料中可以确认的是，他长期以较小规模、较少人员维护产品，并曾公开分享产品收入和经营数据。但不同阶段的产品、收入口径和成本结构并不完全相同，因此不能把零散的收入截图简单相加，也不能据此推导出一个稳定的个人月收入。
从“做一个项目”到“维护一个系统”
定制开发的优势是回款相对直接。客户提出需求，开发者评估工作量，双方确认价格，项目交付后完成收款。对于刚开始经营一人公司的人来说，这种模式能快速验证自己的技术和销售能力。
但它也有明显限制：每个项目都可能是新的技术栈、新的沟通对象和新的交付标准。项目结束后，收入通常也随之结束。若想下个月继续有收入，就要重新寻找客户、谈需求、报价和签约。
Levels 的产品化路径并不是把所有工作都一次完成，而是把某一类反复出现的问题固定下来。例如：
- 用户需要持续查询某种结构化信息；
- 用户愿意为更方便的筛选、更新或社区功能付费；
- 另一类用户需要持续寻找新的工作机会；
- 产品只有不断更新内容，才会继续产生使用价值。
这类需求不适合被包装成“开发完成即结束”的项目。它更像一个需要持续维护的服务：数据要更新，错误要修复，用户反馈要处理，支付和账户系统要正常运行。
因此，订阅收入并不等于“把付款按钮改成按月扣费”。真正的变化是，开发者必须从交付一个功能，转向维护一套持续产生价值的系统。
产品选择：先找重复需求，而不是先想收费方案
这个案例值得注意的地方，不是他找到了一个神奇的订阅定价，而是产品本身具有重复使用的理由。
如果用户只需要一个结果，或者只在某个特定时点使用服务，那么订阅通常很难成立。例如，一份定制报表、一套企业官网或一个一次性数据导出工具，可能更适合按项目收费。强行改成订阅，反而会让用户觉得不合理。
适合订阅的产品，通常至少具备以下一种特征：
- 信息会持续变化，用户需要反复查看；
- 用户的任务会持续发生，不是一次性完成；
- 服务提供了不断更新的内容、数据或匹配机会；
- 停止付费后，用户会失去持续使用的价值；
- 产品能节省用户长期重复投入的时间。
Nomad List 和 Remote OK 所处的场景，都存在一定的持续变化：城市信息、远程工作机会和用户需求不会永久固定。这为会员费、职位发布费或其他持续收费方式提供了基础。
但这不代表所有目录、社区或工具都能自然变成订阅产品。关键仍然是用户是否有明确的回访理由，以及产品是否值得持续维护。
定价验证：不是先算成本，而是观察用户是否愿意留下
一次性项目的报价，常常从开发时间、复杂程度和客户预算出发。订阅产品的定价则多了一个问题：用户为什么要下个月继续付费？
这会改变定价验证的方式。
早期产品不一定需要设计复杂的套餐。更重要的是尽快让真实用户完成付费，并观察几个结果：
- 用户是否愿意在没有一对一销售的情况下购买；
- 用户使用的是哪个功能或内容；
- 用户是否在一段时间后仍然回来；
- 用户取消订阅时，原因是价格、需求消失，还是产品没有达到预期；
- 用户是否会主动反馈问题，甚至推荐给别人。
对一人公司来说，低复杂度定价往往比“功能很多、套餐很细”更容易维护。每增加一个套餐，就可能增加权限逻辑、客服解释、退款处理和数据分析成本。
Levels 的公开创业方式强调快速发布和持续迭代，这种方式有利于尽早验证收费意愿。但快速上线也有代价：早期产品可能不够完整，用户体验不稳定，开发者需要在反馈、修复和新增功能之间不断取舍。
所以，定价验证不是一次决定，而是一个持续过程。第一次有人付费，只能说明“有人愿意买”；只有用户持续使用并续费，才能说明价值具备一定稳定性。
订阅收入的核心指标不是首月收入，而是续费
一次性项目最容易关注的是成交额。订阅业务则必须关注收入质量。
假设一个产品本月获得一批新用户，但下个月大量取消订阅，那么新增收入可能只是短期波动，不能被理解为业务已经稳定。反过来，即使新用户增长不快，只要老用户持续留下，现金流也可能更可预测。
这里至少要区分几个概念：
- 新付费收入：本期新增加的付款；
- 续费收入：已有用户继续付款；
- 流失率：用户在某个周期内取消订阅的比例；
- 平均收入：每个付费用户在一段时间内贡献的收入；
- 回本周期：获得一个用户所花的成本，需要多久通过收入收回。
公开资料通常更容易看到“收入达到多少”，却不一定能看到完整的续费率、退款率和获客成本。缺少这些数据时，就不能仅凭收入峰值判断模式是否健康。
这也是这个案例对一人公司创业者最重要的提醒：订阅收入看起来像一条平滑曲线，但真实经营中仍然可能有明显波动。新产品发布、平台流量、季节变化、价格调整和用户需求变化，都会影响当月收入。
客户从哪里来：公开构建降低了获客门槛，但没有消除获客
Levels 的一个明显特点，是长期公开记录产品开发和经营过程。开发日志、产品数据和个人品牌，帮助他获得了超出普通冷启动产品的关注。
这种方式对独立开发者有几个好处：
- 产品发布前就能积累一部分关注者；
- 用户可以看到产品如何迭代；
- 开发者的个人信誉成为产品信任的一部分；
- 反馈和传播能够在公开讨论中发生。
但公开构建并不等于免费获客。它通常要求开发者持续表达、回应用户、处理争议，并接受产品表现被公开比较。不是每个开发者都适合长期经营个人品牌，也不是每个产品都能靠开发日志获得稳定流量。
对于原本依赖定制项目的开发者来说，这里存在一个现实冲突：接项目时，时间直接换收入；做公开产品时，写文章、发布更新和回答反馈，短期内可能没有直接回款，却又是建立产品分发渠道的一部分。
如果完全停止接项目，把全部时间押在产品上，就会增加现金流压力。如果继续接大量定制需求，又可能没有时间把产品做深。这不是效率问题，而是资源分配问题。
他放弃了什么：确定性、短期回款和客户付费的明确反馈
从一次性项目转向订阅收入，收益比较容易被描述：收入可以重复、产品可以标准化、边际交付成本可能下降。
但代价同样真实。
第一，前期回款更慢
定制项目往往在签约、阶段交付或验收时产生收入。订阅产品则可能需要经历开发、测试、发布、获客和多轮调整，收入积累通常更慢。
在产品尚未验证之前，开发者要承担时间成本和机会成本。对于没有储备资金的一人公司，这是非常现实的压力。
第二，不能只做自己喜欢的功能
定制项目中，客户需求虽然可能琐碎，但付费意愿通常已经被明确表达。产品业务则可能出现另一种情况：用户说“这个功能很好”，却不愿意付费；或者大量用户提出建议，但真正影响续费的只有少数问题。
开发者必须区分：
- 用户觉得有趣的功能；
- 用户愿意为之付费的功能；
- 用户会因为缺少它而取消订阅的功能。
三者并不相同。
第三，获客成为长期工作
产品上线后，开发工作可能暂时减少，但获客不会自动结束。搜索流量、社区传播、内容发布、合作渠道和口碑推荐，都需要持续投入。
如果产品只靠开发者个人曝光获得用户，一旦停止更新内容，新增用户可能就会下降。所谓“被动收入”往往只是把交付工作换成了分发、维护和留存工作。
第四，收入仍然会波动
订阅收入提高了可预测性，但不会消除不确定性。用户可以取消，支付渠道可能出现问题，竞争产品可能改变市场预期，平台规则也可能影响流量。
因此，订阅更准确的含义是“有机会形成重复收入”，而不是“收入自动稳定”。
失败尝试同样重要：不是每个产品都值得继续
独立开发者经常同时尝试多个产品。这样做的好处是可以快速寻找机会，坏处是注意力容易分散。
一个小产品即使能够上线，也可能面临：
- 用户数量不足；
- 用户愿意使用但不愿付费；
- 付费用户太少，无法覆盖维护时间；
- 获客成本高于用户生命周期价值；
- 产品价值依赖某个外部平台；
- 开发者个人兴趣下降，无法持续运营。
公开创业故事容易集中展示最终留下来的产品，却忽略了被放弃的项目。实际上，收入模式转型往往不是一次成功，而是通过不断关闭低潜力项目，把时间集中到更有持续需求的产品上。
这对外包开发者尤其重要：不要因为已经投入了很多开发时间，就继续维护一个没有续费迹象的产品。沉没成本不能证明市场存在。真正值得继续投入的证据，应该来自用户付费、持续使用、续费和明确反馈。
给一人公司创业者的可借鉴部分
这个案例不能证明“辞掉外包、做 SaaS 就能获得订阅收入”。它更适合拆成几个可验证的判断。
先把重复需求找出来
如果你在定制项目中反复实现类似功能，可以记录客户真正反复购买的部分。不要只看代码是否能复用，还要看客户是否有持续需求。
能复用代码，不等于能复用市场。
先验证付费，再扩大功能
一个能让真实用户付费的简单版本，往往比一个长期没有用户的完整系统更有信息价值。验证重点不是功能数量，而是用户是否愿意为结果付款。
把续费当作产品反馈
首批用户的购买只能验证兴趣，续费才能验证持续价值。取消订阅的原因，也可能比新增注册数量更有参考意义。
给自己保留现金流缓冲
如果从定制项目转向产品，应该提前估算在没有稳定产品收入的情况下可以维持多久。具体的税务、合同和财务安排需要结合个人情况咨询专业人士，但现金流压力本身不能被忽略。
不要把个人案例当成普遍规律
Levels 拥有技术能力、公开表达能力、互联网分发能力和较强的个人品牌，这些条件并不是所有独立开发者都具备。他的结果可以提供观察角度，但不能直接复制。
最后：订阅收入不是终点，而是一种持续交换
从一次性项目转向订阅收入，本质上不是把收费周期从“一次”改成“每月”，而是改变了开发者与客户之间的关系。
定制项目的核心问题是：我能否按约定交付？
订阅产品的核心问题是：用户为什么下个月还要留下？
前者更依赖项目管理、沟通和交付能力；后者更依赖持续价值、用户反馈、产品维护和现金流管理。两种模式都可以成为一人公司的经营方式，也都各有压力。
这位独立开发者的经历真正值得参考的地方，不是某个收入数字，而是他把产品当作持续经营的业务，而不是完成上线就结束的作品。对于正在做定制开发的人来说，最稳妥的转型也许不是立刻放弃所有客户，而是先从现有项目中识别重复需求，用小规模产品验证付费和续费，再决定是否逐步减少低价值的定制交付。
订阅收入可以提高收入的连续性，但它不会替创业者免除获客、维护和经营责任。只有精品在用户持续需要、愿意持续付费时，订阅才真正成立。
暂无评论内容