这是一个创建于 312 天前的主题，其中的信息可能已经有所发展或是发生改变。
先自我介绍一下，我是Reqable的开发者，也是 HTTPCanary （小黄鸟）的作者。我在 2022 年初从商汤辞职开始全职独立开发，算起来大约有两年的时间。在 2023 年终之际，给大家分享下我这个阶段的独立开发心得和经验。
我在全职独立开发的这两年里，只做了一个项目，就是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 项目上做对了一些事情，但是也做错了不少，比如：
- 产品在海外的宣传和推广没有用心，也没有花时间。
- 没有实地去接触和了解企业的真实需求。
- 未深度使用 GPT 等 AIGC 工具来提高工作效率和质量。
在 2024 新的一年里，我会花更多的心思去探索海外和 toB 的业务，希望明年底可以写一篇这方面的总结文章。
感谢各位的阅读，预祝大家新年快乐，2024 产品大卖！
 |
1
waterlaw 312 天前 via Android
OP 太强了，独立开发要有一定经济和实力，我目前只能在公司的框架内修修补补，每天老老实实上班。
|
 |
2
viiii 312 天前
钓鱼佬点赞!
说的很实在, 祝越做越好 |
 |
3
fdghjk 312 天前  2
我用还不行吗
|
 |
4
buptspig 312 天前
我用还不行吗
|
 |
5
chenqh 312 天前
太强大了,太卷了
|
 |
6
ingxhe 311 天前
一直在用 Reqable
|
 |
7
ajaxgoldfish 311 天前
op 牛逼，说个题外话，在学习逆向的路子中没少用黄鸟，问一下黄鸟还计划维护更新吗
|
 |
8
cocang 311 天前
在知乎看到过大佬 9 月份的开发分享，独立开发确实不容易，产品也确实棒
 |
 |
9
lizhenda 311 天前
分享的很好，看的出都是自己的感悟。
|
 |
10
neochen13 311 天前
老哥好，postman 这个工具当保存的请求越来越多的时候，就会越来越卡，不知道老哥的产品会不会也有这个问题呢
|
 |
11
fzls 311 天前
大佬牛逼啊，有用过小黄鸟，蛮不错-。-
|
 |
12
batnss 311 天前
大部分 app ,设置了代理和导入了证书后都联网失败, 包括微信小程序;
有些可以,比如 x 浏览器, pdd, 闲鱼等; ---小米 13p |
 |
13
Chad0000 311 天前
有用知识，感谢 OP 分享。
|
 |
14
uxff 311 天前
强大！加油！
|
 |
15
taosimple 311 天前
我也是独立开发，很佩服你的执行力。虽然你也提到了，不过还是有点好奇为什么选择这样一个开发和营收都比较有难度的方向🤣
|
 |
16
zengxs 311 天前 via iPhone
感谢分享很有启发
|
 |
18
love2328 311 天前
想了解下 软件的官网是用啥搭建
|
 |
19
i33 311 天前
体验不错，想知道技术栈是什么？用什么开发的？
|
 |
20
starcode 311 天前
加油！
|
 |
21
w741069229 311 天前 via iPhone
大佬，乘着过年订阅有优惠吗
|
 |
22
block0 311 天前 via Android
分享太肝了
|
 |
23
pengtdyd 311 天前
《 Reqable 的安装包在 20M 左右》想问一下 OP ，这个是如何做到的？？？
|
 |
24
summereyt666 311 天前
大佬加油
|
 |
25
dnddk 311 天前
感谢分享，值得收藏学习。祝产品大卖！！！
|
 |
27
dys0327 311 天前
@ajaxgoldfish #7 reqable 就是替代黄鸟的
|
 |
29
liferoll 311 天前
厉害,给大佬加个油
|
 |
30
uni 311 天前
第四点太有体会了，本来对 postman 就没有好感但是被后端同学按头使用，没办法那就用吧，但是要登录，内网环境根本用不了，就骂骂咧咧地把它删了
|
 |
31
xliao 311 天前
如果我没猜错，这个有使用门槛的远程桌面软件是 t o desk
|
 |
32
INW017bzMfgkkYGn 310 天前
楼主做生意很实在，之前买了 HttpCanary ，今年竟然被『强制』赠送了 2 年 HttpCanary👍🏻
|
 |
33
MegatronKing OP @xliao 你] 兄弟有点东西哈🤣
|
|
34
MegatronKing OP @ajaxgoldfish #7 过去时了，reqable 就是替代品。
|
|
35
MegatronKing OP @pengtdyd #23 框架是 flutter 。Flutter YYDS ，Windows 极限情况下能控制到 10M ，因为 Reqable 移植了 Chromium 的网络框架、MiSans 字体和一些 windows 可能缺失的运行时库，差不多额外大了 10M 。目前，各个平台安装包差不多都在 20M 附近了。
|
|
36
pengtdyd 310 天前
@MegatronKing 如果是用的 flutter ，那状态管理用的是哪一个？
|
 |
37
patrickyoung 310 天前 via iPhone
@MegatronKing #34 有没有 feedback email? 还是 github issue only?
|
 |
38
AllNewDesign 310 天前
佩服!!!
同样独立开发,而且自认为做的不差,但是面向这个群体我属实无法乐观坚持这么久. |
 |
39
huangliu 309 天前
很多观点都和 OP 不谋而合，持续做有益的事情坚信总会有回报的，2024 继续加油😁
|
|
40
MegatronKing OP @pengtdyd #36 Bloc
|
|
41
MegatronKing OP @patrickyoung #37 github issue only
|
 |
42
stobacco 309 天前
支持 我去查看了邮箱，发现 23 年 7 月就补偿了买 HTTPCanary 补偿的激活码，感谢 op
|
Select Language