Wade Foster 找到那条帖子时，它已经旧了大约八个月。
发帖的人是 Mixergy 的 Andrew Warner。他想把 PayPal 里的资料自动带到 Highrise。Wade 当时正在为刚起步的 Zapier 寻找用户，这看上去很合适：有人公开说出了需求，也能明确指出需要连接哪两个工具。
但 Wade 没有直接把它当成一张等待成交的订单。他先写信问：这个问题现在解决了吗？如果解决了，用的是什么办法？
按 Wade 在 2012 年 6 月的回顾，三天后收到的答案是：已经解决了。
故事本来可以在这里结束。旧问题仍然留在网上，现实中的人却已经往前走了。对方不再需要那条连接，团队也还没有把它做出来。仅凭搜索结果判断需求，两边都会被想象得比实际更接近成交。
不过，Andrew 仍对他们在做的产品感兴趣。继续交流后，另一个问题浮了出来：他需要把 Wufoo 和 AWeber 接起来。
这也没有现成的功能可交付。Wade 找到 Bryan 和 Mike，团队花了几天做出这条连接，再告诉 Andrew 可以用了。对方询问价格，他们报价 100 美元，作为进入测试期的费用。Andrew 接受了。
这笔钱并没有让事情自动完成。Wade 的回顾里，后续几周仍有设置帮助、一次 Skype 演示，以及专门为这位用户补上的过滤功能。他承认当时界面很难用，也明确说，这种交付方式尤其按 100 美元的价格看，并不是可以直接规模化的销售过程。
另一位创始人 Bryan 在 2011 年 10 月的起点记录里，早已写出两项担忧：能否及时做出可演示的程序，以及能否让业务人员和非技术用户理解并使用。第一笔付款出现以后，第二项工作仍然摆在那里。
我读这个故事时，最在意的是需求改变的那一刻。
团队最初找到的是一条旧线索，实际交付的是另一项当下任务。线索有价值，因为它帮助双方开始交流；它的价值不在于替客户把今天的需求也决定好。
这对独立开发者很实际。搜索帖子、看产品评论、整理用户抱怨，都容易产生一种错觉：只要把被提到的功能补上，需求就仍然在那里。但使用者可能已经换了工作方式，买了另一款工具，接受了手动操作，或者不再做那项业务。公开文字没有消失，不等于问题保持原样。
可以把一次需求核对写成三行：当时为什么困难；今天怎样完成；现在还有哪一步值得改变。三行之间允许出现断裂。比如，旧流程已经不用了，就不必硬把谈话拉回自己准备开发的功能。
假设你在做文件整理工具，看到一位摄影师半年前抱怨照片批量命名。这是一个假设案例。交流后发现，他已经有稳定的命名方式，现在真正费时间的是区分客户确认过的版本。此时，“又找到一个需要重命名的人”就应该从记录里划掉。新的任务要重新理解：谁确认、在哪里确认、确认以后文件还会不会变化。
即使对方愿意为新任务付款，也还需要确定这项工作适不适合自己的产品。可以先写出最小交付：接收什么输入、产出什么结果、遇到什么情况由人处理、怎样认定已经完成。这样才能看清，自己是在补一项可复用的能力，还是开始维护一套只适用于某个人的流程。
支持时间也应该记下来。讲解设置、修正误解、处理异常，都是这次交付的一部分。第一位客户愿意耐心配合，是很有用的学习机会；但他的耐心、知名度和付款，不能替代下一位普通用户的独立使用。
因此，接到第二个相似需求时，我会先核对它究竟相似在哪里。若输入、规则和结果都不同，只是界面上看起来都叫“同步”，就不应轻易说已经找到了重复销售的方法。
Zapier 的这段早期经历让我记住一个具体的工作顺序：尊重旧问题可能已经解决，听清新的任务，完成一笔明确交付，再检查哪些部分值得继续复用。
资料与时间：
- Wade Foster，《The Anatomy of Sales at a Startup or How Andrew Warner Became Our First Paying Customer》，2012 年 6 月 25 日：首位付费客户回顾。
- Bryan Helmig，《Startup Weekend Part I - The Idea》，2011 年 10 月 4 日：创业周末的起点记录。
两篇文字阅读全文核对日期为 2026 年 11 月 6 日。历史经过按创始人的公开叙述整理，100 美元是当年的测试期费用；摄影师案例与核对方法为本文独立建议，没有实际访谈或试用结果。
