图 1：本文封面，漏斗末端那枚硬币才是验证的终点。
有个做工具的开发者分享过自己的做法：先不急着写产品，做个落地页讲清楚解决什么问题，挂个付费入口看有没有人真掏钱，有人付了再动手开发。靠这套打法，他的小工具上线早期就收到了一笔相当可观的收入。具体数字只有作者自述、无法核验，但打法本身值得拆——它的核心不是「多快赚到钱」，而是「多便宜地知道想法错没错」。
核心结论一句话
SaaS 小工具的验证是五步流程加一道决策门：痛点假设 → 落地页与等待名单 → 预售或付费意愿测试 → 最小功能开发 → 订阅收费上线。决策门立在第三步和第四步之间：有人愿意付钱才继续，没人付钱就换题，而不是加大投入。验证的目标不是证明想法对，而是用最小成本尽快知道它错没错。
第一步：把痛点写成可检验的假设。
「我觉得大家需要」不是假设，「什么角色、在什么场景、愿意为解决什么麻烦付钱」才是。检验标准只有一个：这句话能被证明是错的吗？能被证伪的才叫假设，不能证伪的叫愿望。优先从自己天天遇到的麻烦里找——你自己是目标用户，验证成本天然减半。
第二步：落地页与等待名单。
一页纸讲清三件事：解决什么问题、给谁用、大概长什么样，尾部放一个「上线通知我」的邮箱收集。这一步的纪律是能不写代码就不写——落地页用建站工具拼，表单用现成服务接。然后把页面放到目标用户聚集的社区里，看访问量到留邮箱的转化。留邮箱只是兴趣信号，不是付费信号，所以它只是入场券，不是通行证。
第三步：付费意愿测试，决策门在这。
把「通知我」升级成「现在预订」：挂一个真实的价格和支付入口，或至少发起预售。愿意点支付和愿意留邮箱之间隔着验证的全部价值——口头兴趣免费，掏钱有成本，只有后者能证明需求真实。这里要诚实对待结果：几十个访问零付费，是想法或定价错了的信号，回头改假设；有人真金白银付了，才拿到走向第四步的门票。门后永远挂着一条回退箭头：没人付钱就换题，沉没成本不是继续的理由。
图 2：五步流程、决策门与两张原则卡。
第四步：最小功能开发。
只开发付费用户买的那条核心链路，能手工的先手工——早期「产品」的后台可以是你自己加电子表格，用户拿到价值就行，自动化等需求被反复验证后再补。验证期的省钱原则一句话：能不写代码就不写，落地页、表单与手工服务先顶上。
第五步：订阅收费上线，配齐付费闭环。
SaaS 的钱在订阅，订阅的工程要件是三件套：支付接入、订阅周期、退订路径，一次配齐。好消息是这些不需要自己造：以 Stripe 为例，创建订阅后会自动生成账单并尝试扣款，订阅对象有试用中、生效、逾期、已取消等一套明确的生命周期状态，失败支付的重试与催缴由平台承担，状态变化通过 webhook 通知你的系统——你要做的是监听这些事件来决定开通还是收回访问权限，而不是自己写一套账单状态机。第一笔钱到账，验证才算真正完成；之前的一切都是彩排。
三个常见误区。
误区一：用点赞数当验证。点赞、收藏、「这个我也想要」的评论都不花钱，决策门只认付费动作。误区二：过了门就放开做。付费验证只证明「核心需求存在」，不证明「十个周边功能值得做」，最小功能的纪律在门后依然有效。误区三：把收入数字当方法论。别人晒的收入截图无法核验也无法复制，能复制的是「先验证后开发」的顺序——盯顺序，别盯数字。
给你的行动建议。
挑一个你自己每周都遇到的小麻烦，今天只做到第三步为止：写一句可证伪的假设、拼一个落地页、挂一个真实价格的预订入口，发给二十个目标用户。一周之后看数据：有人付钱，排期开发；没人付钱，恭喜你用一杯咖啡的成本排掉了一个可能吃掉你三个月的想法。
你验证过自己的 side project 吗？卡在了落地页、定价还是付费入口？欢迎聊聊。