我在全职独立开发的这两年里，只做了一个项目，就是Reqable。Reqable 是一个全平台的抓包和 API 测试工具，可以理解成 Fiddler/Charles + Postman 。这是一个看起来非常没有前景的独立开发方向。首先，这是面向开发和测试人员的产品，而众所周知程序员的钱并不好赚（笑）；其次，这是已经严重饱和的存量市场，无论是开源的、免费的还是付费的，替代品众多；再者，项目工程量大，相当于一个人要做 Charles 和 Postman ，而且是桌面端 + 移动端全平台。Reqable 桌面端在今年 6 月份正式上线，移动端在今年 12 月中旬正式上线，真正的营收窗口期只有 7 个月，虽然收入远达不到辞职前的水平，但是可以看到营收曲线有一个很好的增长趋势，我相信 2024 年会进入一个扩张性增长的阶段。
现今这个时代，互联网的红利早已经被吃透，到处都是存量市场。创意的爆款产品也就那么些许，很多时候除了创意更多还需要运气，可遇而不可求。因此，很多的独立开发者不得不和我一样在存量市场里摸爬滚打。尽管 Reqable 项目目前算不上成功，我还是想给大家分享下我的关于如何在存量市场里生存的一些看法，全当抛砖引玉了。
1. 有鲜明特色的平替
在存量市场里面，后来者是以挑战者的姿态出现的，目标是争夺市场份额。市场的需求是固定的，后来者需要提供竞品可替代的功能，最简单有效的方式就是抄功能。当然，抄袭前人并不可耻，可耻的是毫无特色的抄袭或者是全盘照抄。在存量市场里，竞品可能已经做了十年甚至二十年，他们沉淀多年的设计或者交互大多已经成为这个行业的习惯或者默认规则，我们这些后来者没必要闭门造车，该抄的抄。当然，一个非常重要的原则是取其精华，去其糟粕，用腾讯的话来说叫做“微创新”，用我的话来说叫做“有鲜明特色的平替”。
平替，意思就是要替代掉对方或者替代掉对方的某些功能，而不是另起炉灶，自我创新，虽然我们鼓励创新，但是强行改变用户习惯的代价和不确定性太高。当然，替代的过程可能是极为漫长的，我们可以先从核心功能做起，慢慢地逐步地实现竞品所有的功能。比如 Reqable 的目标是替换掉 Postman 的 API 测试功能，但是 API 测试相关的功能太多了，比如 HTTP 、WebSocket 、GRPC 等等。这些功能里面用得最多最频繁的肯定是测试 HTTP 请求，所以我第一个做的功能就是 HTTP 请求测试，界面和交互基本都是遵循的 Postman 。
上图两者界面和交互看起来几乎一样，实际上却有很多细节做了优化。比如 URL 做了语法高亮配色，更简约的设计，更便捷的类型切换等等。在底层技术方面，Reqable 支持 HTTP2 和 HTTP3 的请求测试，而 Postman 并不支持。这是很多 Postman 用户的痛点，近几年 HTTP 的协议版本在持续发展，Postman 却已经滞后了，护城河留下了一个缺口，落后就要挨打。虽然 Reqable 远不足以挑战 Postman 的地位，但是能吃到一部分的用户也是非常好的。
2. 创新点也必不可少
全面去复制竞品的功能虽有可取之道，但替换的太过于漫长，我们可能等不到成功的那一天，因为对手也在更新也在进步。竞争对手是一个成熟的团队，独立开发者是一匹独狼，以小搏大是不切实际的。所以，我们仍然需要寻求创新点，开辟一个新的方向，寻找一个新的道路。
在做 Reqable 项目之前，我曾经调研了 Postman 的一些功能，发现它有一个捕获 HTTP 流量的功能，也就是抓包，但是做得非常的简单，是下图这个样子。
而我们所常用的一些知名抓包软件也支持编辑和发送 HTTP 请求，比如像 Charles 的 Compose 功能，参考下图。
无论是 Postman 还是 Charles ，他们交叉的功能都是浅尝辄止。对于用户来讲，完成一件事情，这两个工具可能都要用到。我们不妨想象下这样的一些场景，小明使用 Charles 抓取到了一个请求，想要进一步测试或者保存，就需要在 Charles 中复制 cURL 导出，然后打开 Postman 里面导入 cURL ，发送请求测试，保存到 API 集合。又或者这样的一个场景，小红在 Postman 里面测试一个请求，发现了些问题，她可能需要打开 Charles 抓个包，来看看网路中实际的流量是什么样子的，来进一步分析定位这个问题。如果有一款工具，能够深入地整合这两者，并打通中间的壁垒，那么一定会有市场。
那么，如何深入整合呢？首先是打破隔阂，可以在从抓包流量中直接创建 API 进行测试，可以在发送 API 请求的同时记录抓包的流量。接下来，进一步的抽丝剥茧，寻找两者之间的共同点进行整合。比如，都需要使用脚本来控制请求或者响应，都需要使用变量功能来代表一些动态的数据，我要做的就是一个功能同时应用到两个方面。
除了功能的创新，还有一个非常重要的就是覆盖范围。无论是 Postman 还是 Charles ，都只能在桌面端上工作（其实 Charles 还有个 iOS 版本）。在手机越来越重要的今天，移动端已经是一个不可或缺的平台了。所以我的另一个突破点就是桌面端 + 移动端全面覆盖，并提供两端协同功能。比如抓取手机端的流量无需再设置 Wifi 代理，手机扫码连接电脑，直接将流量转发到桌面端的 Reqable 上进行处理。
3. 帮助用户无缝转移
很多时候我们总是一心想着去超越竞争对手，而忽略了用户对于竞争对手的粘性。用户从一个产品转移到一个新的产品，是有非常大的沉没成本存在的。除了功能的平替外，还需要考虑如何帮助用户转移。这也是我今年做的非常不好的一个地方，没有能够在产品层面帮助用户来降低这个转移成本。比如，下图就是一个用户的真实反馈。
再比如很多用户使用 Postman 或者 ApiPost 等工具，他们的 API 数据都存在于这些软件上面，这些用户改用 Reqable 后必然希望能够导入 Postman 等软件的数据，我要做的就是尽最大努力来支持。
4. 不要设置使用门槛
我觉得空讲这个话题不着地，所以还是结合前几天我遇到的一件事情来谈谈我的看法。
事情是这样的，有一个用户向我反馈 Reqable 在他的电脑上无法配置系统代理，热心的他表示可以配合我使用远程桌面进行调试，然后告诉我他用的一款远程桌面软件。我没听说过这个软件，自然电脑上也没有安装，然后我就去下载了一个。安装包 120M 左右，家里网络不错，很快就下好了，打开安装也没什么问题。安装完成，打开软件，弹出界面让我输入账号密码登录，看到这个我心里有点不爽了。想想还要解决问题，无奈选择微信登录，扫码，手机点击确认。登录完成，让我输入手机号，这时候我就有点恼火了，反手直接删除软件。这个远程桌面软件看起来还是有一定市场份额的，我就不透露名字了，免得惹麻烦。
也许这个远程桌面软件不缺我这一个用户，但是远程桌面软件产品这么多，我也不缺这一个。这个远程桌面软件好不好用，流不流畅，清晰不清晰我压根儿不知道，因为我进不去，进不去是因为我不想告诉他我的手机号。登录账号并不是远程桌面连接的必要步骤，如果我来开发一款软件桌面软件，我一定会遵循安装即用的原则。当然，在我的 Reqable 产品里面，也是严格遵循这样的原则，安装即用。在做 Reqable 之前，我调研过相关的竞品，比如 Postman 、ApiPost 、Fiddler 等等，也都是明确要求登录，甚至不登录不给用。我就只想测试个 API ，只想抓个请求，要登录搞啥呢？
此外，关于安装包的大小，120M 的软件安装包大小，在网络一般的情况下，下载可能需要 2-5 分钟，安装后需要占用 300M 的空间。我的 MacBook 工作机只有 256G 的存储空间，剩余容量不多（没办法，IDE 还有一些代码仓库占用就是大），这是另一个使用门槛。我想，如果我来做一款远程桌面软件，我会希望能够将安装包控制在 30M 以内，大幅降低这个门槛。Reqable 的安装包在 20M 左右，安装后大约有 60M 空间占用，这是一个让我非常满意的体积，像竞品 Postman 有 400M 占用呢。
当然，我的项目 Reqable 在降低使用门槛上做得也不够好。比如有一个用户安装后无法上网，就卸载换成 Insomnia 了，因为 Reqable 在最初的设计里面会默认给用户配置中间人代理。这是一个非常深刻的教训，因此我在后续版本进行了一些优化。
5. 迎合你的用户群体
不同的产品有不同的使用群体，不同的群体有不同的审美和习惯，我们要做的就是迎合这些用户。
比如我的 Reqable 的用户人群是开发和测试，因为我本身就是程序员，所以我相信我还是非常了解这个群体的，比方说我们喜欢简约的设计风格、喜欢流畅的运行效率、喜欢用键盘而不是鼠标、更偏爱暗色的应用主题，喜欢小而美，喜欢专注而不是分散，等等等等。
在设计产品的风格、交互、使用习惯等方面的时候，都需要紧紧围绕我们的用户群体，让他们满意。如果用户群体是女性，那么可能需要更亮丽的色调；如果用户群体是儿童，需要的是卡通化的设计。
6. 做有耐心的垂钓者
很多独立开发者在项目刚上线的一段时间内可能没有收入或者有微薄的收入，这时候往往还能克制，然而当项目有了一些起色，就开始想着如何赚钱，开屏广告、横幅广告、付费功能或者涨价等等，每个页面都写着两个字是要钱。诚然，赚钱是商品的本质，但是没必要那么急不可耐，竭泽而渔。在存量市场竞争里面，这无疑是自寻死路，也是给新产品上位的机会。
先说定价。没有用户不喜欢免费的产品，如果是处在”环市场皆要钱也“的环境里面，免费和低价可以给予产品极大的优势，这也是中国制造独步全球的秘诀。在绝大部分市场里面，高价的干不过低价的，低价的干不过免费的，这是市场规律。当然，如果完全免费用爱发电也不适合独立开发者，毕竟是也是要养家糊口的。我的观点是，免费和付费可以并行，让白嫖的用户用得舒服，让付费的用户用得更舒服。免费可以更快地积累用户基数，付费可以缓解财务窘境。
这和钓鱼是一个道理，虽然我不是钓鱼佬也很多年没有钓过鱼了，但是钓鱼的过程我还是很熟悉的。钓鱼需要先打窝，打窝就是将气味浓郁的饵料扔到水里，通过这些饵料来吸引鱼群。类比到产品，免费就是打窝的饵料，不要因为免费的饵料被鱼吃了感到心疼。打完窝，我们就可以钓钩挂食开始钓鱼了，钓钩上的食物肯定比打窝的饵料要更有吸引力。钓鱼不是捕捞，讲究的是姜太公钓鱼——愿者上钩，可能河边坐了半天也没有鱼儿咬钩，但是你要是想下水捞一把，那鱼群可能就散了，得不偿失，还湿了裤子。
在产品上线初期，我们通常会用免费或者低价来和竞争对手抢用户。在积累了足够多的用户后，我们可能需要优雅地提高价格，或者增强用户的付费意愿。但是要注意，和下馆子一个道理，让客人忌讳的是涨价不涨量。软件产品和实物不一样，软件没有原料成本上涨的困扰，涨价一定是要建立在产品持续迭代、推陈出新的前提下的。好的做法是，在保留免费用户权益的基础上，推出需要付费的新功能，或者产品涨价让用户获得更多的权益。
下面给大家分享一个真实的例子。在 Reqable 项目内测期间，有幸认识了另一位全职独立开发者。我们在聊天的时候，他向我分享了一个有关他的某个项目的经历。大致意思是他的产品在内测期间还有不少用户，口碑也还挺不错的，正式上线后开始收费了，然后就没用户了。虽然他的产品定价比竞争对手低，不过也是半斤八两，功能差不多定价又没有优势，产品也就黄了。
我们需要做好产品在很长一段时间内都没有用户，没有收入的心理准备。坚持长期主义，戒骄戒躁，寻找原因，一切慢慢都会好起来的。
7. 2024 年继续加油
这篇文章是关于我的产品如何在存量市场里生存的一些可能不成熟的见解。2023 年即将过去，回顾这一年里，我在 Reqable 项目上做对了一些事情，但是也做错了不少，比如：
在 2024 新的一年里，我会花更多的心思去探索海外和 toB 的业务，希望明年底可以写一篇这方面的总结文章。
感谢各位的阅读，预祝大家新年快乐，2024 产品大卖！
