从 0 开始做 SaaS：先验证问题，而不是先写代码

开场：不要把灵感误认为机会

很多 SaaS 项目的第一天都很兴奋。开发者看到一个行业里还在用 Excel、微信群、邮件和人工复制粘贴，就立刻想到：“这里一定需要一个系统。”然后开始画架构、选技术栈、注册域名、写登录页。

几个月后，产品确实上线了，但客户没有来。来过的人也只是说“挺好的”，却没有留下预算、时间表或真实业务数据。这时候团队才发现，自己验证的是“能不能做出来”，不是“有没有人愿意为它改变工作方式并持续付费”。

从 0 开始做 SaaS，第一步不是写代码，而是验证一个问题是否真实、具体、足够痛，并且属于你能服务的客户群。

SaaS 机会不是功能空白

一个行业没有某个工具，并不代表这个工具有机会。可能是客户已经有替代方案，虽然粗糙但足够用；可能是问题存在，但不值得专门付费；也可能是采购链条复杂，个人开发者很难触达决策人。

早期判断 SaaS 机会时，至少要分清三个层次：

真正值得做的 SaaS 问题，通常不是“缺一个漂亮系统”，而是某个流程正在持续造成损失：销售线索跟丢、客服响应慢、账单对不上、数据重复录入、客户交付不可追踪、权限混乱、合规风险无人负责。

从具体客户开始，而不是从巨大市场开始

早期最容易犯的错误，是一上来就说“面向中小企业”“面向电商卖家”“面向所有知识工作者”。这些描述太宽，宽到无法做产品决策。

更好的写法是：

• 面向每月处理 300 单以上售后工单的独立站卖家。
• 面向 10 到 50 人、还没有专职运维的小型软件团队。
• 面向需要把学员报名、收款、排课和通知串起来的线下培训机构。
• 面向同时使用飞书、企微和表格管理客户交付的小型咨询团队。

客户越具体，你越容易判断他们在哪里、谁有预算、现有流程是什么、替代方案是什么、第一版要做什么、不该做什么。

如果目标客户说不清，产品就会自然变成大杂烩。你会不断听到不同人的需求，然后把它们都放进待办列表，最后做出一个谁都觉得“有点像”，但谁都不急着用的工具。

访谈要问行为，不要问态度

很多需求访谈无效，是因为问题问错了。

不要问：

• 你觉得这个产品有没有用？
• 如果我做出来，你会不会用？
• 你愿意为这个功能付费吗？
• 你希望它长什么样？

这些问题容易得到礼貌答案。对方不想打击你，也没有必要当场做真实承诺。

应该问：

• 上一次遇到这个问题是什么时候？
• 当时谁参与处理，花了多久？
• 最后是怎么解决的？
• 过程中有没有出错、延误或返工？
• 现在用什么工具或流程替代？
• 如果问题继续存在，一个月会损失什么？
• 解决这个问题的预算现在归谁管？
• 过去有没有为类似工具付过费？

行为比态度可靠。客户过去怎么做，往往比他说未来会怎么做更接近真相。

一个简单的验证分数表

你可以用下面这张表给点子打分。每项 0 到 2 分，总分低于 8 分，就不要急着进入开发。

这张表不是为了制造精确结论，而是防止你被自己的热情带偏。一个低频、低损失、无预算、难触达的问题，即使技术上很好玩，也不适合作为第一个 SaaS 项目。

先卖结果，再卖系统

早期客户不关心你用了什么框架，也不关心后台是否完整。他们关心结果：能不能少漏单、少催人、少对账、少解释、少出错。

所以在验证阶段，不一定要先做完整产品。你可以先用手工方式提供服务：

• 用表格和脚本帮客户整理数据。
• 用简单表单收集信息，再人工生成报告。
• 用现成工具拼接流程，观察客户是否愿意持续使用。
• 用一个静态页面说明方案，收集预约和试用申请。
• 给 3 个目标客户做一次付费试点。

如果客户连手工服务都不愿意付费，很可能也不会为自动化系统付费。反过来，如果你用粗糙方式已经能收钱，产品化才有基础。

判断付费意愿的几个信号

早期不要只听“可以试试”。更可靠的信号包括：

• 对方愿意约下一次正式演示。
• 对方愿意提供真实数据或流程文档。
• 对方愿意介绍同事或老板参与。
• 对方主动问价格、发票、合同、权限和数据安全。
• 对方愿意为试点支付小额费用。
• 对方愿意明确一个上线时间。

这些信号说明产品进入了真实工作，而不是停留在闲聊层面。

如果客户一直说“等你做完整了再看”，要警惕。完整不是早期产品的前提，明确痛点才是。如果问题足够痛，客户会愿意和你一起定义一个可用的最小版本。

常见误区

第一个误区，是把自己的问题当成市场问题。开发者经常从自己的工作流出发做工具，这当然可以，但要确认是否有足够多相似的人也在承受同样问题，并且愿意为它付费。

第二个误区，是把功能请求当成购买承诺。客户说“能不能加一个审批”“能不能支持导出”“能不能对接某个平台”，不代表他会买。每个功能请求背后都要追问业务场景、频率和付费动机。

第三个误区，是过早扩大人群。早期产品应该先在一个窄场景里打穿，而不是同时服务十种客户。窄不是小，窄是为了让你把价值讲清楚。

第四个误区，是害怕谈钱。很多人觉得产品还没做完，不好意思报价。其实早期谈钱不是为了马上赚大钱，而是验证客户是否把这个问题当成真实预算项。

第一阶段的退出标准

在进入 MVP 开发前，最好拿到这些证据：

• 至少访谈 10 个目标客户。
• 找到 3 个以上高频、具体、相似的问题场景。
• 明确一个客户画像，而不是宽泛行业。
• 知道客户现在如何解决，以及为什么不满意。
• 至少有 2 个客户愿意参与试点。
• 能用一句话说清产品承诺的业务结果。

一句话模板可以是：

我们帮助「某类客户」在「某个高频流程」里减少「某种损失」，不需要他们改变整个系统。

从 0 开始做 SaaS，真正的起点不是代码仓库的第一次提交，而是你第一次确认：这个问题有人正在付出代价，而且愿意让你参与解决。