EP26 独立创客访谈录 - Megatron:小黄鸟& Reqable 作者

Summary

本期播客节目讲述了独立开发者的转型历程，以 Megatron 的创业经历为核心，探讨了他们在产品开发、用户反馈、技术选型和商业化过程中所面临的挑战与机遇，同时强调了个人品牌建设在独立开发者成功中的重要性。

Takeaways

• 独立开发者能够掌控产品方向，避免大厂流程的限制。

• 处理用户反馈和资源不足是独立开发者的重要挑战。

• 在产品类型选择上，市场验证过的项目风险较低。

• Megatron 在图书馆独自开发 Reqable 的经历展现了独立开发的艰辛与机遇。

• 技术选型应根据产品需求和自身能力进行评估，Flutter 具备跨平台优势。

• 低付费率的原因包括免费版功能完善及国内用户习惯，出海是扩展市场的策略。

• 对于品牌策略，无需当前品牌隔离，未来可能需重新规划。

• 个人品牌运营需注重社交媒体推广与社区互动。

Q&A

Q: Megatron 如何看待从大厂转型为独立开发者的心路历程？

Q: 你有没有考虑过外包或者是虚拟助手来处理非核心的工作？

Q: 能不能聊一聊这个项目的技术选型？

Q: “你现在几个平台，几个端，用户量多少？”

Q: 你对产品的商业化情况和路径有什么看法？

Q: 国外有没有一些第三方的这种软件的安全性分析的这些，公司、机构？

Q: 为什么 Megatron 现在不运营推特？

Outline

• (00:00:02)从大厂技术骨干到独立开发者：转型之路与心路历程

  本章以独立开发者 Megatron 为例，探讨了从大厂技术骨干转型成为独立开发者的过程。Megatron 分享了自己两次创业的经历，以及为何最终选择成为独立开发者。他认为独立开发者能够更好地掌控产品方向，不受大厂内部流程和决策的影响，从而更有效地将自己的想法付诸实践。

• (00:05:09)独立开发者面临的挑战：用户反馈与资源不足

  本章深入探讨了独立开发者所面临的挑战，特别是用户反馈处理和资源不足的问题。Megatron 举例说明了用户反馈的类型，包括功能性问题和 bug 报告。他认为，独立开发者需要兼顾客服、测试和开发的角色，这会消耗大量时间和精力。此外，独立开发者通常缺乏团队的支持，无法像大厂一样分工协作。

• (00:11:19)独立开发者的选择：产品类型与市场验证

  本章讨论了独立开发者在产品类型选择方面面临的两个方向：快速推出多个小产品，或专注于开发一个大型项目。Megatron 分享了自己在两者之间做出的选择，以及他为何选择后者。他认为，市场已验证过的项目能够减少风险，而大型项目需要更长时间才能完成。

• (00:20:16)独立开发者开发之路：图书馆里的 15 个月

  本章重点介绍了 Megatron 在图书馆里独自开发 Reqable 的经历。他回顾了项目立项的思考过程，以及选择大型项目的理由。他坦言，疫情带来的环境影响导致项目开发周期延长，但也让他更加深刻地体会到独立开发的挑战和机遇。

• (00:27:50)技术选型：Flutter 的选择与挑战

  本章探讨了 Megatron 在技术选型方面的思考和选择。他认为技术选型需要根据产品形态和自身能力进行评估，并分享了为何选择 Flutter 框架。他强调了 Flutter 在跨平台开发方面的优势，以及在早期阶段遇到的挑战，例如多窗口问题和代码编辑器开发。

• (00:42:37)商业化之路：低付费率与出海策略

  本章重点讨论了 Reqable 的商业化策略和现状。Megatron 坦言，目前产品付费率较低，主要原因是免费版功能较为完善，以及国内用户付费习惯的影响。他计划通过出海扩展市场，并寻求更有效的商业模式。

• (00:53:13)出海之路：品牌策略与数据安全

  本章围绕 Reqable 的出海策略展开讨论。主持人提出是否需要对产品进行品牌隔离，并分析了利弊。Megatron 从技术、用户体验和数据安全等方面分享了自己的观点。他认为，由于产品本身的特性，以及用户画像的相似性，现阶段没有必要进行品牌隔离，但未来可能会需要考虑重新规划。

• (01:04:23)个人品牌运营：冷启动与社媒推广

  本章探讨了个人品牌运营的策略，并以 Megatron 的推特运营经验为例。主持人分析了 Megatron 停止推特运营的原因，并提出了更有效的社媒推广方法，包括利用社区互动，寻找潜在用户，以及通过软广宣传产品。

Keywords

Highlights

<aside> 💡 (00:02:22) “我还是选择了出来继续创业，只是说创业的话，这次选择的方向呢是，呃，做一个独立开发者，而不是说加入一个团队，因我之前在团队里面会遇到的很多的问题，我觉得就是通过个人开发者的话其实是可以避免这方面的这个呃，这些问题。”

</aside>

<aside> 💡 (00:08:56) “但另一方面，咱们对于这些很棘手的场景一个月解决了，那这个产品力就真的上去了。而且你看，我刚才在想一个话题，咱们先说 2B,2C，但这个产品是 2D 的，是 developer, developer，我们叫 2D 的。Qt 也是一个大产业，Vercel 啊，Intelligate 这些都是，做得好的话也是很不错的。”

</aside>

<aside> 💡 (00:13:20) “你觉得你有没有考虑过， 不是说组团队， 因为你刚才讲的这些工作，不管是做测试还是做客服， 其实是非核心工作嘛。 你因为非核心的工作， 让步自己对公司的控制权肯定不划算，那你有没有找过外包或者是 Virtual Assistant 来做这些事情？”

</aside>

<aside> 💡 (00:23:06) 我当时选择第二个第二个，因为从大巴子的这个工具的角度来讲的话，市场其实并不是特别这个市场其实是一个很完美的一个市场，但是呢，产品并不是一个很好的产品啊，包括像 postman，包括像什么 charles 啊这些产品啊，我觉得这些竞品他其实做的并不是很好......我觉得他是能够获得到一定的市场的。这是经过市场验证的。

</aside>

<aside> 💡 (00:30:00) “我希望说有一个框架能够说我既能够说做这个桌面端又能够做这个移动端，我希望也通过一套代码去同时去去开发，然后打包部署。对，呃，我调研了整个市面的这个框架，框架我发现 Flutter 是最合适的，因为我其实我对 Flutter 其实没什么工作经验啊，我也可能只是说听到大家聊的比较多啊，但是我并没有写过一项代码，但我还是说呃，我因为我要做这个产品，我的产品形态是这样的，那我需要去选一个框架，那选个框架的话就是 Flutter 还是它目前来看它最合适的。”

</aside>

<aside> 💡 (00:45:00) “我觉得这个做的不好。第一个原因就是说还是这个产品的整个的重心，重心呢就是说呃， 我其实主要的过去的这一年啊，主要追求的还是说产品的这个这个用户的增长，而不是说营收的增长。很多想法可能我产品出来了，产品成熟了，我我需要做的就是说做营收啊。其实我的想法就是，这个市场这个这个市场呢，这个赛道它是一个很成熟的一个赛道，它是有非常多的这个竞品。而且你的底气会很差，所以我的这个策略呢就是说我尽量的说不去追求营销增长。”

</aside>

<aside> 💡 (00:54:15) “将来你要去对外去提供云服务，这里面有数据交换的情况的时候，你要对外展示的主体一定不能是一家中国公司，这个是肯定的。即便是从有几个点，我其实也挺纠结的几个人，因为首先一方面它是一个开发工具，用户的行为习惯不管是国内还是国外还是高度相似的，所以说做隔离是合理的。”

</aside>

<aside> 💡 (01:05:10) 如果从里面挑一个先做哪个的问题，这个原则上来讲，我还是推荐先做个人号，但是呢，Reqable 它这个产品有这个比较特殊的情况，所以说拿不定主意，得思考一下。

</aside>

Mindmap

• 转型之路的启示

  • 从大厂技术骨干到独立开发者：转型之路与心路历程

    • Megatron的背景

    • 转型心路历程

    • 开发经历

  • 独立开发者面临的挑战：用户反馈与资源不足

    • 用户反馈的重要性

    • 技术支持与AI工具

    • 产品市场与开发者

    • 团队合作与角色分配

• 成功的选择与准备

  • 独立开发者的选择：产品类型与市场验证

    • 用户反馈的重要性

    • 外包与团队扩展的挑战

    • 知识文档与教育用户

    • 社区与用户支持机制

    • 文档与SEO优化

  • 独立开发者开发之路：图书馆里的 15 个月

    • 项目立项

    • 市场验证

    • 个人经历

    • 社区观点

• 技术与商业化探索

  • 技术选型：Flutter 的选择与挑战

    • 技术选型的重要性

    • Flutter的优势与挑战

    • 用户平台分布

    • 对独立开发者的建议

  • 商业化之路：低付费率与出海策略

    • 用户增长与商业化路径

    • 市场现状与挑战

    • 商业化策略与调整

    • 产品改进与增长机制

    • 未来展望与发展方向

• 跨境品牌与个人成长

  • 出海之路：品牌策略与数据安全

    • 产品品牌隔离的必要性

    • 国际用户的感受

    • 数据安全与隐私

    • 定价策略讨论

  • 个人品牌运营：冷启动与社媒推广

    • 个人与产品的优先级

    • 社交媒体运营的误区

    • 产品与用户反馈的平衡

    • 社交媒体平台的选择与策略

    • 成长路径与未来展望

📢 出海去是一个赋能独立创客的孵化平台，提供产品出海所需的一站式服务（产品选型、海外支付、设计、冷启动、增长、个人 IP 打造等等）

🚀 参与方式：

• 孵化：每期 10-15 位，补齐短板，规避陷阱，从 0 到 1 完成出海

• 会员：在孵化器中零距离学习出海经验（在线群组、孵化例会、大咖分享、知识库等）

更多详情 👉 chuhaiqu.club

Transcript

Speaker 1:

大家好，欢迎来到出海去孵化器新栏目独立开发者访谈录的直播。今天雨晨、百顺、波波和我很高兴邀请到了社区成员 Reqable 开发者 Megatron, 让我们来聊一聊从大厂技术骨干走出来的这些独立开发者有着怎样的转型之路，以及在单枪匹马下 15 个月的时间如何在图书馆里开发出了超过 10 万用户的 Reqable。我们也会探讨成为独立开发者之后， 趟过的河和走过的坑，当然还有产品的下一步出海之路。欢迎大家在直播间参与互动。首先我们来有请 Megatron。

Speaker 2:

大家好，我是 Megatron。

Speaker 1:

好，那 Megatron 是从大厂技术骨干里走出来的，那咱们第一个话题呢，就是聊一聊，得如何从一个大厂的技术负责人，转型成为了独立开发者，那整个的这里面的心路历程，因为很多的群友社区成员啊，包括现场的人，他其实也在大厂里面，不管他们是在官网也好，还是说心有悸动，也想成为一名独立开发者也好，那 Megatron 跟他们介绍一下自己的在过去这两年的这个心路历程。

Speaker 2:

好，呃，我呃，简单讲的就是说我之前呢，嗯，在那个，呃。之前啊就是在前前个公司就就离职之前，我其实说是有过创业经验的，然后呢就是呃我当时呢就是跟一些就是参加加入个也是做 AI 方面的，基本就是比较方便的，对，然后大概做了两年多，然后失败了，对，然后又回去又找了个大厂去上班， 对， 然后到大厂之后的整个的就是整个的状态心态还是说受到之前整个创业的当时的影响，对， 然后就基本上就是很多业内都会说可能说创业这个事情它本来会会有点上瘾，对，

就是说你的整个的你跟大厂里面按部就班的上班跟你说在一个创业团队里面去创业的这个整个的人的状态呀， 氛围呀， 各个方面都是不一样的， 对， 所以我还是选择了出来继续创业， 对， 只是说创业的话， 这次选择的方向呢是， 呃， 做一个独立开发者， 而不是说加入一个团队， 对， 因为呃， 因为我之前在团队里面会遇到的很多的问题， 我觉得就是通过呃， 个人开发者的话其实是可以避免这方面的这个呃， 这些问题。

Speaker 1:

举个例子吧。

Speaker 2:

举个例子的话就是说，就是你在整个的就是大厂里面上班啊，就是不管大厂小厂里面上班，有一个非常重要的问题就是说整个的产品啊，呃，你是没有办法去把控的。对，除非说你是这个整个公司的一把手啊，就是创始人，不然的话你是没有办法去把控这个东西的，就是你，你在里面的话，不管你是说做 CTO 啊，还是说做这个部门负责人啊之类的，你会面临的一个问题说，你只能说把控住一小部分的东西，你没有把控了整个全局的一个东西，比如说这个产品的产品的这个整个的规划，

整个的这个产品的设计， 然后产品的这个技术的架构，对吧，然后包括后面的后面的研发测试等整个的环节的话，就是说你很难去把控到每一个点，但是呢，呃，你如果会不把控到一个点的话，你会发现这个产品跟你的就是想法和方面会造成一个很大的冲突，对，你会看到他一步一步的走向失败而非常的无能为力。

Speaker 3:

这个超级有共鸣，我觉得很多我们社区里面就走，首先你这个用户画像或者是你的这样一个情况，我觉得首先跟我很契合，我也是大厂，然后也有创业经验，然后也做过一段时间独立开发，我跟群里很多群友都是做独立开发时候认识的。就是你刚才讲的这种情况非常感动，就深有同感，就包括你说，即便你做到 CTO 的角色的话，很多时候也就是一个，更多是一个扮演打工跟执行的一个状态。而且但是呢，这个事情反过来你要讲，如果你是 CEO 的话，如果你在一个大团队里面，他就做 CEO 的角色也很痛苦，

就是你很多时候也没有办法去完全掌控方向，你可能大方向有一些，但是一些细节自己也没有办法保证完全能按照自己预期来做。但是做独立开发的话，或者类似于人工色的这样的概念，你是能够彻底的掌握住整个产品的脉络，但是你会不会觉得有的时候就相比以前有个大团队的话，做独立开发有没有一些特点或者不足，就或者是资源不够啊，有一些原先能实现，但是现在一个人必须得要舍弃的一些，就不能光有好处嘛，总有一些舍弃的事情。

Speaker 2:

嗯，对，是，嗯，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，呃，�状态还可以，但是说在技术之外，你知道一个成功的产品的话，不光是技术啊，包括你的运营，包括你的客户的维护，包括你的这个整个的对客户提出一些问题的，你的一些及时的一些响应啊，等等各个方面，包括说这个推广，呃，

包括商务各个方面自己东西非常的多，然后呢就是说你整个的就是说呃，比如举个例子啊，就像我现在可能这个产品大概可能是几十万用户的这个量级了， 那面临一个问题就是说你会每天收到非常多的这个用户的反馈。对，你可能每天可能有大概有可能几十个用户来找你，然后他们说这个产品这个不会用啊，或者说这个产品呢，我这个使用的过程中可能会有一些 bug，对，然后需要你帮忙去做一个排查之类的定位啊之类的。对，这个其实是一个非常浪费时间的一个，因为它包含了两个角色，

一个角色呢是这个你是要维护客户关系，对，你现在是个客服的客服的角色，第二个还有一个就是说你是一个测试的角色，因为用户提出了问题，你得去测试去复现，对吧，然后整个的整个的就是前面这两个这两个角色的话，你需要担任的，但如果说这个问题确认了，你可能还要去做问题的修复啊，就得定位之类的，那可能还要扮演一个开发的一个角色， 对，对我来讲的话，就是说我能够承担开发这个角色，但是前面这个客服这个角色跟这个测试这个角色，就是说我，呃，从这个经历方面来讲，会感到这个有点吃力。

对，这个相对于一个团队来讲的话，就是说，呃，会很面，因为团队里面基本上就是说，呃，客户维护啊也好，客服啊，包括这个测试，这个觉得很多是专门有一个角色来干的，而不是说全归到一个人身上，对这个就是一个很呃，我觉得是目前遇到的一个很呃，很苦恼的一个事情。

Speaker 1:

嗯。Feedback 的用户的纯反馈和他提出的问题，哪个比例更高一点？有的是他要问一下怎么使用，我们算这个功能性的，还有一些是认为他有问题的，这两个哪个比例更高一点？

Speaker 2:

嗯，一半一半吧，都有一半一半。

Speaker 1:

那有没有考虑过就是用户 Feedback 这一部分可以用一些 AI 工具来解决？我看也有大的独立开发者和一些公司开始尝试了。

Speaker 2:

嗯。呃，这个的话，哎呀，这个方面的话，其实说啊，我没有太过于去呃，全面的考虑过，就是从目前来讲的话，更多的其实是一个技术性的东西，因为因为我这个产品它本身是一个技术性非常强的一个一个工具，是的，对，然后嗯，技术性非常强的一个工具，它是包括很多的整整个的一些文档呀，一些教程呀，其实呃，很多网上搜研的收到很多。但是呢，就是但是呢，整个的就是在有文档有教程的这个前提下呢，还是有很多的用户说没有办法去解决，因为什么呢？因为网络它是一个很复杂的问题啊，网络它跟其他的你的软件，

可能你的界面的出现一个 bug 什么之类的不一样，网络这个 bug 它非常的难以比如说你这个防火墙，你家里的网络环境，路由器，对吧，等等各个方面的东西，他的设计的点非常的多，就是说呃，很多时候可能我自己排查的时候也没有办法去能够帮助我去解决好，因为他确实是一个呃，嗯，呃，环境非常多，然后条件也非常复杂的这样的一个一个东西。

Speaker 1:

你能想象得出去派他这样的工作是很花时间的。但另一方面，咱们对于这些很棘手的场景一个月解决了，那这个产品力就真的上去了。而且你看，我刚才在想一个话题，咱们先说 2B,2C，但这个产品是 2D 的，是 developer,developer，我们叫 2D 的。

Speaker 3:

Qt 也是一个大产业，Vercel 啊，Intelligate 这些都是，做得好的话也是很不错的。

Speaker 1:

咱们经常说这些开发者难付钱，从他们身上弄钱真的很难，可是呢，你反过来讲，如果真的是有很好工具的话，说实话，不管是国内国外的开发者，周日春逛还是可以的，如果真的遇到好产品，他们是愿意付钱的，尤其在国外嘛，这也是为啥说咱们这个产品在国内已经拥有了几十万用户，有这么好的这个产品底子，这样的产品出海是很值得期待的。嗯。刚才 Megatron 和宇诚都说了一个事儿，我都说一个旁观者，你们都提到说我在大厂工作的时候是创过业的，在大厂工作的人可能没有你俩这么激动的心，但是在那创过业了，

就发现在大厂里面工作真的不如自己干，刚才 Megatron 就提这个感觉，我不知道理解对不对。

Speaker 3:

对，我觉得但凡你想要去做创业肯定他，因为很多人他如果没有这个心的话，他应该都不会往这个方向想嘛，但凡有这个激动的心的话，他其实，嗯，你就是早晚的事情了，不会，就这只是个时间早晚的问题，就时机，时机把握的问题，就觉得只要你愿意想要去做的话，你基本上呆大厂呆不住了，嗯，有一些如果是因为一些经济上的原因，客观因素呢，就要呆着没办法，那就更难受。Um, what would you rather?

尤其是像我们社区里面很高密度的都是这个人，就基本上， 撑不住的，就是你， 你， 给他在好的公司里面的代理人也撑不住。

Speaker 1:

嗯， 尤其他们现在还有很多是在副业， 副业尝试独立开发吗？嗯， 我们说是激动的性能已经被打开一半了。

Unknown Speaker:

嗯， 对。

Speaker 1:

刚才 Megatron 说的这个关于 feedback 这事，我是觉得作为独立开发者，我又看到一些比较大的东西，像 Facebook 上面很出名的我们叫八眼或者叫背眼，你看他的产品用户数也达到至少是上百万级别了吧，他每天你看一大半的工作也是在不停的汇复邮件，不停的汇复邮件，他就觉得这个事咱不能说这个用户不好啊，就这个事情真的是每天会占据到自己大量的时间，还是希望有这样的产品啊，AI 产品能够是尽量的把麦克创这样的高级独立开发者的心理给摆脱出来，

有招招客招客就想做做这个事情吗？但是那个我想。

Speaker 3:

对对对，然后我， by the way, 赵贺是我们上次那个帮助我们在 7 月 20 号杭州线下组织这个提供场地，然后他也是我们社区的成员，然后最近在做一个企业性的项目出来，这个就先放开一边不表啊，就是刚才提到就客户支持以及这一类的繁琐的工作啊，其实延伸出来的话就两个方向，就是如果你想要解决它的话，有两个方向来做。一个方向就是你尽量做 to be 的，尤其是 to 那些高额客单价的 to be 的。因为你要么它摊得很薄对吧，然后数量很多，要么就是做成很厚但是很窄，

就是说你可能只服务一少部分人，比如说不超过一百个人。而不是服务十万的人。但是这一百个人， 客单价可能也很高。最后算下来的话， 你可能从你的个人收益上来讲， 并没有太大区别。这可能是能够减缓你这些购物售后啊， 克服一些压力的一些方式吧。当然 to be 有 to be 的问题， 就是他们可能对于你克服的这些反应啊以及服务是否到位， 就复杂度会更高一些。这是一种方向， 就是减少你的服务的对象。另外一个就是扩容， 就是扩你自己的 support 的能力，

就是这个我其实也想问问 Megatron, 就是你觉得你有没有考虑过， 不是说组团队， 因为你刚才讲的这些工作， 不管是做测试还是做客服， 其实是非核心工作嘛。你因为非核心的工作， 让步自己对公司的控制权肯定不划算， 那你有没有找过外包或者是 Virtual Assistant 来做这些事情？

Speaker 2:

嗯，而且觉得不太信任他们，嗯，呃，这个的话我觉得就是说呃，是可以的，因为比如说像现在这个国内的一些大厂啊，比如说像说一直做这个呃，技术服务相关的，比如说什么呃，阿里云啊这些他们一般的工单的整个的工单一般也是交给外包团队去做的，他们肯定不是说自己的工作人员去处理的，对，就是说呃，通过外包团队其实可以过滤掉，我觉得应该是可以过滤掉 80% 的这些这些问题。嗯，对，真正的可能就是说，嗯，还有 20% 的可能才会流入到我这边，这个确实是一个比较好的，但是呢，从这个承蒙各个方面来讲，

就是说，呃，在整个的产品的这个营收没起来之前的话，啊，还是得忍一忍，我其实有一个对我一个想法是其实是我们可以通过呃，写比较详尽的 tutorial。

Speaker 4:

就教程类的东西来达到这个事先先教育客户的目的，然后再采用这个一些就是类似于机器人对话机器人的方式去把这些内容给采集进去来做智能问答，这样可以也可以过滤掉大部分的这个客户请求，成本也可以得到愉快的控制。

Speaker 1:

详尽的问答，因为开发者这个群体呢总体来说可能比其他群体还稍微聪明一点，理解能力比较强，学东西也比较快。

Speaker 4:

Do it.

Speaker 2:

嗯，呃，整个的就是这个应该是属于这个整个的这个基础服务吧，基础服务系统，呃，从这个文档，文档肯定是一个非常重要的一个方面，呃，呃，但是呢，呃，其实开发者看文档的不多，我了解下来啊，就是说跟一些呃，朋友呀，做开发的一些朋友啊，他们说他们基本上说，呃，拿到一个产品第一遍，他不是说先去看这个文档，先去看这个产品怎么使用，还是说上来就用了， 用了之后，然后看自己用的感觉好不好，然后有没有问题，对，然后有问题了，他们可能会有的人呢，可能会直接就去找文档了，

对，有的人可能就打文档，可能也不会，他可能就直接希望有能够得到一个人工的服务，因为他们他他想我我已经付费了，对，我付费了之后，我必然说我需要享受这样的一个人工的一个指导，对，你需要一个真实的人来帮我解决这个问题。呃，我不知道就是呃各位就是呃有没有这样的一个想法，就是说我遇到一个问题的时候，我付费了。对，然后呢就是呃他们会觉得这个整个的机器问答各个方面的时候，达达达到点。他们更希望说我能够有境外有一个人工的介入。有没有可能是国内的产品，尤其技术产品，它的文档做的实在是太辣了。

Speaker 4:

对，我也有这样感受，是我这两年其实被国外的产品给，就是其实把好脾气给培养出来，就是过去我们在国内的这个做社会支持的时候，客户是巴不得你跟他提供这种及时的，对吧，实时的这种社会支持的，但是我们就我用了这么多海外的产品，基本上做的好的，他都是两个东西，两个呃方式实现了这种客户请求，一个就是刚才提到了详尽的文档，另外一个就是他们建立了一个就是用户的社区，他们采用了一些所谓的产品大使，这些产品大使在社区里面行使的教育其他用户的智能，就相当于是脑袋心的这种感觉。

Speaker 1:

咱们评论区里细细就说这个事，不可以考虑让用户交用户，高阶用户带链，低阶用户给他们搞事情。

Speaker 4:

Thank you for watching.

Speaker 3:

对，我觉得作为论坛或者作为社区挺值得考虑的，就是这个方向，尤其是你的基础客户在这儿，就考虑在做出海的同时起一个英文的开发者社区，我觉得还是可以考虑。

Speaker 2:

呃，我想过，嗯，就是我想过通过 Github 去做这个事情，因为 Github 我觉得它是一个很好的，很好的这个社区，就不需要做自己去独立搭一套这个系统，嗯，这个不知道可不可行，可行，可行，因为我我目前在维护一个 6000 多 star 的开发项目。

Speaker 4:

然后我们主要的用户的功能请求以及 bug 的汇报，包括一些 UI UX 方面的改进，这些全部是在 GitHub 上面的 discussion 来实现的。其实本质上来说它也是一个我们把它当作讨论区，然后因为它里面的通知功能也比较完善，所以我们把它整合进了我们整个的开发测试的工作流。我觉得从反馈机制上来说是一个很好的体验。

Speaker 1:

而且 Reqable 这个纯开发者类的产品，从产品形态上来说，它比百顺的 HitFarm 更适合在 GitHub 建立社区。

Speaker 4:

是的，嗯。

Speaker 1:

评论区 Nothing 说 Reqable 这个文档是很好的，夸你一下。

Speaker 2:

哎，文档大概我其实花了很多的时间啊，就是我其实看了一些国外的一些竞品啊，就是国外的竞品的大部分呢，可能都文字会比较多，图片会比较少，那我做文档的时候我的一个想法就是说呃，尽量的能用图来表达出来的，尽量用图来表达对呃，所以我这个我整个文档里面的图片的占比会非常的多，文字的占比相对来说比较比较少一点嗯，用过心的这么用心，大家不点个赞吗？谢谢大家。

Speaker 3:

但是图片文档可能有个问题，对搜索引擎优化不是很友好。谷歌他不知道这个图片描述什么内容。

Speaker 2:

是的，而另外呢，就是说图片文档呢，它的一个比写文字的话，它的一个花费的成本跟经济要费要大很多，因为你你图片你可能需要编辑，可能会要附加一些说明，会牵扯一些重要的东西之类的。对，然后呢，包括你的产品的这个呃，你的 UI，你的布局，你的这个交互发生了变更之后，你这些图片你需要做一个及时的更新。

Speaker 1:

那咱们切下一个话题，就是作为独立开发者本身，因为我知道咱们这个产品是一个人在上海封城期间，还在图书馆里用了 15 个月的时间，就这个所有的因素加起来，它不太像一个小的独立开发者走过的路线，可能从大厂，尤其这种技术上的这种高阶的，我称为高阶独立开发者， 这个路线我们都比较感兴趣，一年多的时间闷在图书馆里。

Speaker 2:

嗯，我先说我的想法吧，就是说，嗯，还是说从这个项目立项啊，立项的立项开始，因为这个项目立项呢，就是说它是在，呃，我，嗯，在离职之前离职之前大概一个月左右的时间是才开始立项的，对，然后关于这个立项呢，我，呃，当时在想这个我如果说啊，如果说我当时想想我如果说我现在辞职了，我现在要出来这个，呃，做独立开发者，然后创业，我要做什么东西？对，然后大概呢，我想了想，大概有两个方向，可能也是很多这个独立开发者面临的一个选择，第 1 个呢，是我做这个短评快的。

然后铺量，我可能说这个一个做一个一个很多个产品，每个产品可能大概可能花个一个月，我一年可能大概可以给出 10 多个产品，我靠的 10 多个产品呢，就是说每个他们可能量不是很大，但是 10 个加起来可能量就很大了，或者说我的这 10 多个产品呢，可能可能死掉了 10 个，可能大概剩两个是能够盈利的，这样也能说不定也能不起来，那是一种，那是一个方向啊。第二个方向呢就是说我说我做一个呃大的大的大一点的项目，这个项目呢你需要可能需要花几几个月十几个月去完成，

但是呢他的整个的用户市场呢你得到了验证，然后呢你的你要做的就是说跟市面上已有的这些产品是个竞争，对，然后这个呢就是你需要花走一个长走一个长线，对，这两个方向就是说我觉得也是很多人呃包括我当时很纠结的一个点， 到底是选哪个方向，这两个方向呢就是说说呃。我其实之前也都有个经验啊，也都做过，因为我之前呃，在可能应用上呢，也做过很多小的单品啊，就是可能花花个几个星期就做出来的这个产品，也能卖到钱啊，这也是对，然后也做过这个花了花了几年的去做一个一个产品，

这个也做过对啊，最后呢，我还是选择了说说第二条路啊，就是说我去我希望做一个这个市场已经验证过了，然后呢，你市场市面上有竞品，然后有成熟的产品，然后呢，就是你需要通过时间去雕刻这样的一个更好的一个产品，然后去跟他们竞争，去抢他们的市场的份额。对，呃，这是呃，所以我当时选择第二个第二个，因为从大巴子的这个工具的这个角度来讲的话，就是说呃，这个市场其实并不是特别这个市场其实是一个很完美的一个市场， 但是呢，产品并不是一个很好的产品啊，包括像 postman,

包括像呃什么 charles 啊这些产品啊，我觉得这些竞品他其实做的并不是很好，他其实只是说做的早。从这个用户体验各个方面来讲的话是说非常的就是被大家诟病，所以说你如果说做一个呃功能跟他们差不多，然后呢你这个呃稍微有一些创新，然后呢你从你的这个 UI 你的这个交互各个方面你做的比较好，我觉得他是能够获得到一定的市场的。对，这是经过市场验证的，然后但是负面的就是说他整个的一个周期生产的周期会非常的长，因为他涉及到到的这个呃，比如说这个跨多安。

很多的可能有他们他们积累了这个 10 多年的功能，你都要去做，但是一个长期的一个事情。对，然后我既然是说我选择了这个长期的这个论断，就是说呃，我当时的这个立项之后，这个心理预期大概可能是花 8 个月。对，我一开始的这个大概的估算是 8 个月，8 个月的时间把它，呃，做一个基本差不多的东西出来，但实际上还是说，呃，高估了这个，这个高，就是高估了这个自己的这个能力跟整个的产品的这个，呃，发展的这个节奏，因为什么？因为当时这个疫情啊，疫情出来之后，然后就是，呃，

其实影响还是还是挺大的，对，虽然说这个我是全是独立，但是影响还是很大的，因为呃，长期分泌在一个地方，整个的呃，你你的所需要的这个 idea 啊，各方面就感觉呃，受到了限制，我就当时很很这个很常见的一个事情，就是说我面临的一个交互，我面临的一个呃，意外的一个设计，对，然后我经常会可能一个星期也想不出一个好的一个头绪出来。对，因为你没有办法说去，呃，跟别人去做一个，呃，交流，对，你没办法去线下去，可能说轻松一下大脑，然后说突然间有一个灵感出来了，

对，呃，这个就是说当时是很苦恼的一个地方，另外就是说你，包括你自己整个的就是你知道在在家的有时候效率很低，因为你要做饭， 对吧，然后各个方面你可能点不了外卖，不想上班啊，可以吃食堂，点不了外卖等等，整个的这个节奏的受到了就是受到很大的限制，所以说后面大概有将来就整个在整个的这个前期的规划上大概多了六个月左右的时间，半年左右的时间该做完。

Speaker 1:

这个路线在咱们这个社区里的成员其实并不多见，因为大多数人呢不管是受到国外的那些知名的独立开发者影响，就是我一年干 20 个产品，我只要能撑仨我就赢了。首先，这个产品形态就不是一个短片块的产品，它是一个开发者的套件。再一个，Megatron 是经过了长时间的思考，包括它之前在大厂工作的时候，它就已经开始涉及到这个事情。再一个，人家有小黄鸟的基础，我估计现场有不少人还用过这个产品，它是因为有这样的产品基础，它走向了现代这个产品，它不是说在大厂里就这么脑袋一热，

我就开始做一个一年多的产品，我还把它做出来。

Speaker 3:

对，我这边就想特别想 echo 一下，就是反正你两种方式，一种是要么你做这个非常明确有市场需求的，你可以时间多花一些时间来试探， 要么如果你这个产品本身有很大的市场风险，所谓的市场风险就是它没有经过市场验证，它很大概率你卖不掉，有很大的市场风险的话，那你就尽量快的速度，挑产品形态的时候也是挑小一些的，就尽快把它做出来以后，花大量的精力跟时间去做市场验证。千万不能做什么呢？就是做一个既要花很多时间，尤其独立开发，花很多时间才能做出来，

然后它本身又没有经过市场验证，那也就是两边都不讨好。

Speaker 1:

嗯， 给大家想清楚这个，你看鲍里说小黄鸟 YYDS，咱们这个评论区啊，有一个问题，我在我们在直播开始之前的时候我们简直聊天就提到了这个，说今儿啊可能就得聊聊这个东西。痕迹说， 能不能聊一聊这个项目的技术选型。说实话， 咱们在直播的时候， 面对的大多数的技术类的， 也不是技术类的吧， 独立开发者， 其实我们不太聊技术选型的事儿。但今儿呢， 比较特别， 因为它就是一个面向开发者的产品。然后小龙的技术呢， 也是国内火鱼餐饭的 Flutter 嘛。

可能很多人想知道 Megatron 在技术选型的过程。说实话， 技术选型这个事， 做技术的人可能在第一时间想到的还不是产品， 还是技术选型的问题。正好 Megatron 去聊聊， 以及最后选 Flutter 的过程。波波也是 Flutter 的忠实爱好者。

Speaker 2:

呃，呃，我简单的谈一谈我的想法吧，呃，就技术这个方面呢，就是说，呃，我觉得并不是说所有的东西都需要说，呃，绑死某一个技术吧，因为从我个人的这个开发经历来讲，就是我接触过很多的这个很多的语言，包括就是以前我一开始做安卓，可能 java，然后 kotlin，然后包括可能后来做嵌入式，c++, 然后包括呢还经常用的一些比如说测试的 python 呀， 包括还做过游戏啊， 做过游戏，然后写过 csharp, 写过 unity, 等等就是说，呃，我其实说整个技术上还是比较丰富的，

嗯，但是说，呃，你说我是不是一定要偏爱某种语言，说我做技术选项的时候我就就说我需要偏爱某一个东西呢？其实我觉得并没有，其实我的一个最怎么呢？就是想法就是说我这个项目它适合用什么东西去做？然后你这个项目它本身的形态是怎么样的？就比如说像我这个项目，我的项目它本身是就是我的设想，它是一个多平台的一个项目，它需要覆盖的桌面端加移动端。对，然后呢，我当时从开发的这个角度来讲，就是说从承蒙啊，就是你跟你讲，呃，你如果说桌面单单独的去开发一套，

你移动的再单独的开发，这个成本也是非常高的，就对我来说，它是难以接受，不管说你用什么语言啊，什么框架去做，它都是难以接受的。我希望说有一个框架能够说我既能够说做这个桌面端又能够做做这个移动端，我希望也通过一套代码去同时去去开发，然后打包部署。对，呃，我调研了整个市面的这个框架，框架我发现 flutter 是最合适的，因为我其实我对 flutter 其实没什么工作经验啊，就是我也可能只是说听到大家聊的比较多啊，但是我并没有写过一项代码，但但我还是说呃，我因为我要做这个产品，

我的产品形态是这样的，那我需要去选一个框架，那选个框架的话就是 flutter 还是它目前来看它最合适的，那我就需要说去然后就去去学习这个框架，然后去使用这个框架， 然后使用这个方向它确实能够能够说达到我所希望的这样的这个产品的这个这个形态能够做出来，那我就就就选择这个框架吧。假如说啊，我如果说我不做这个这个移动端，我只做只做只做这个桌面端，就是桌面端，那我可能觉得 Frata 肯定并不是一个很合适的一个框架，因为呃，从我当时做的 2022 年来看的话，

整个 Frata 的这个框架在这个桌面端的还没有正式发布，还属于这个 beta 版本啊，就是它的问题还还是很多。对，然后你在桌面上可能有很多更成熟的框架，包括可能像 Electron, 像那个像这个 Qt，或者说其他的一些啊，REN 之类的等等啊，就是说有很多，呃，更可能更合适的这个框架，框架选型，对，如果说我做桌面呢，我可能就是大概率啊，大概是不会选 flutter, 我可能就选 Electron 之类的。然后这是一个，这是一个就是从产品形态的一个点来看啊，

就是说你要选什么框架，你就是还是要根据这个产品，你希望它是一个什么样的形态，它支持哪些平台，你希望于，你希望说呃，你需要付出哪些成本。对，其实个人就是从程序员的角度来讲啊，就是每个语言啊也好，这种框架它其实本身没什么太大的区别啊，因为什么呢？就是说这个。就是说这个各个现在的这些程序语言都高级语言，它的本身的这个共性非常的多，上手的这个呃，你如果说你你会一两门语言，你再学一门新的语言，它的上手的一个速度应该应该应该也是非常快的，

而对于说宽价来讲，宽价来讲就是大概的就是说你泡泡呆沫啊，看看文档，然后写写写写也差不多了，其实并没有说有什么卡关的一些地方。对，然后再聊一聊就是我当时选 flutter, flutter 的时候那是 22 年开始做嘛，22 年开始做，然后那时候桌面端他还没有正式发布，所以我当时做的时候也遇到很多问题。哎，包括这个整个的就是比如说这个大家可能经常说比如说这个多窗口的问题，对吧？然后比如说在这个对原生的一些平台，比如说 windows 的上面的一些特殊的平台，

一些功能的知识，mac 的一些知识，nuke 的一些知识等等啊，包括后来做移动端。同样的就是包括移动端的这个交互跟桌面的话，它是完全不一样的等等，就是它有很多的问题，但这些问题就是说都需要花，呃，花精力去解决，嗯。但是最后还是解决的，最后其实都是解决了，但是呢，可能有的某些地方呢，花了很多的时间，比如说呃，最典型的就是说这个代码编辑器吧，代码编辑器不像 electron, JS 这些框架，它本来有，比如说有 CodeMirror，有这个 MicroEditor 等等啊，

就是呃，它的这个水平很多，但是它并没有有一个好的这个编辑器，所以我其实花了很大的精力去写这个编辑器，大概可能花了前前后后制造也得也有三个月吧， 大概可能也是这个时间花的很多，就是最难啃的一个点啊，最后也啃完了，呃，所以呢就是说，呃，嗯，啊，当然也是比较幸运的，就是也是比较幸运的解决了这个问题，但是如果说这个问题解决不了，那可能就是这个项目可能也就失败了。

Speaker 1:

呃，就是三个月的时间要去解决他本身编辑的问题。

Speaker 2:

对，然后就是说对于这个有什么建议呢？我的想法就是说，呃，呃，第一个点就是产品形态吧，看你产品现在选什么框架。第二个呢，就是说你有没有能力去解决这个框架本身的问题。呃，比如说要浮在这个框架他宽宽维护的呃，能解决问题其实并不多啊，就大部分还是得靠开发者自己自己去解决，你可能需要查资料也好，你可能说自己去用别人的话，别人的这个插件也好，或者自己写一个插件也好，这个是还是挺考验个人个人个人能力的，就是说如果说对这个东西不太自信的话，一般还是呃，

不太建议呃，不太建议选这个不成熟的这个这个框架。你可能还不如牺牲一些功能，还是选一个成熟的框架会比较好。

Speaker 1:

Arthur 毁于参半， 毁的就是刚才 Megatron 点出一个重点，官方解决的并不多，基本上都得去自己解决，然后呢本身可能技术上没到那个位，大部分人也许也没有能力三个月的时间去解决一个，因为编辑器，文本编辑这个功能在所有的这种 UI 里面是比较困难的一种技术。然后刚才呢， Megatron 提到一个重点，就为什么叫 Flutter，因为要顾及移动端。我的理解是，如果当时没有移动端的话，咱也不用这个。

Speaker 2:

是的。

Speaker 1:

嗯。

Speaker 3:

那我刚好想问一下，就你现在几个平台，几个端，用户量多少，就根据你前期，就刚好好奇问一下吧，就是因为现在可以做一些复盘或者回过头来看，就是你可能花了很多精力在不同的平台上，那从用户使用率来讲，就几个平台的使用率或者是用户数，大概分布是什么情况？

Speaker 2:

嗯，说孵化的话，大概是呃，最多的还是安卓平台呀，安卓平台比较多，因为主要是受以前这个呃，小黄鸟的这个产品的这个引入的影响，就是大部分可能 50% 的用户基本上都是都是由以前的这个产品引流过来的，所以说呃，因为以前只有安卓这个平台嘛，所以现在这个安卓平台是目前最多，大概可能会占到 10% 到百分之四五十的样子。对，然后剩下的就是最多的就是 windows 平台，其次呢就是 macOS, 这个比例大概 windows 大概会占到 40% 左右，

然后那个 mac 可能只能占到 8% 左右吧，8% 9%，然后 linux 的话就很少，linux 可能只能占到 1% 了，可能甚至 1% 你可能还不到， 对，所以如果大家做这个大发类工具的选型的话，就是桌面端我觉得还是优先做 windows 端会会会好，因为 windows 端我从我这边的情况来看的话，那个 windows 的大概是其他桌面端的大概是 5 倍左右。对，但像我这个产品它比较特别的安卓的比较多，还是说受以前产品的这个这个影响。

Speaker 1:

桌面作战这个比例也大概是各个操作系统的市场占比整个整个的这个趋势还是对应的嗯，波波爱也是这个 Flutter 的应该是爱好者吧，或者生态效的一员，我之前，我不是爱好者，我是我是众多的实践者，哈哈哈哈，我这不是怕那个说众多实践者说都偏了吗，至少说个爱好者是不会错， 博博对这个事呢，你是不是想跟 Megatron 讨论的？两个 flutter 的成员。

Speaker 5:

嗯，就是之前我在那个公司带团队的时候，其实我们那个 flutter 用的非常重的，然后我刚进去的时候，我们当时是纯 native 的嘛，对，然后当初选 flutter 的原因主要就是为了降本增销， 对，然后后来反正慢慢引进，包括也用了闲鱼的那个 flatboost 那档方案，就是很多人在喷，但是当时哎，我是哪一年？19 年啊，19 年对，19 年年底的时候，当时 flatboost 是混编，其实是当当时最好的方案了，包括后面几年的话，

其实我们自己有去维护那个 flatboost 我觉得还是解决了我们当时团队的一个问题，所以我觉得移动端你说有什么太多的问题，其实就是要看你怎么用，就是如果你是一些常规的业务的话，其实法拉盛没有什么没有什么任何的毛病啊，然后像刚才那个呃，提到的就是说如果像编这种东西，那的确有点那个，有点吃力，然后刚才包括我看了一下那个咱们这个项目的开源 GitHub 那边，就那个 re-editor，其实我很早就收录了，对我很早就知道 re-editor, 然后今天终于见到了作者。

I think... 还是可以尝试的吧，就是包括包括那个现在很火的那个突突应用嘛，就 superlist 就他们是完全重仓 flutter 的，包括那个桌面端移动端都是都是都是主要是用 flutter 写的，然后部分的逻辑是用 rust 嘛，对，然后啊他们也开源了一个那个啊 superlist 的一个 editor, 对，所以我觉得 flutter 还是一个值得尝试的一个技术的一个方向吧，但是话又说回来，就是如果是独立开发者， 我觉得要慎重，

因为它相对于用比如说用 web 生态，就是包的那些，比如说 RNN 什么的，Electron 什么的，就是它的研发成本相对来说会高高一些。就是如果独立开发，我觉得要慎重。

Speaker 1:

尤其是作为桌面产品，你有没有这个能力三个月去种藏一个文本编辑器这样一个很复杂的功能？你如果没这个能耐的话，考虑考虑啊。

Unknown Speaker:

这个不是开玩笑。

Speaker 5:

桌面那边的话，其实我之前做过一款产品也是桌面的应用，然后当时我的想法跟那个 Megatron 是一样的，就是我也要覆盖全部的平台，什么 Windows, Linux, Mac，什么 iOS, Android 都要覆盖，对，当时一开始是这个想法，后来的话就是就覆盖到了 Mac，因为产品没做起来，其他平台就不用覆盖了，因为就是虽然说就是说它的跨平台就是说的很好嘛，但是还是有一些些的要兼容的一些东西要做的啊，然后包括还包括当时还集成了 Rust, 所以这个东西对我的成本就更高了，

所以最最终只只只兼容了 Mac, 在还在没有兼容其他平台之前的产品已经死了。

Speaker 2:

其实我刚刚还漏了一个点，就是我补充一下，就是说刚刚不过刚好提醒了，就是比如说 superlist 他可能用的那个 rust 对吧，其实一样的，我这边的话其实是说 flutter 除了 flutter 之外，其实很大的很大的一部分就是功能就是在这个 CGI 里面的，对，我其实现在我这个项目其实是一个 flutter 可是 flutter 可能内部的很多的东西就是用 CGI 去做的， 就跟可能像是不是用 Rust 去做可能差不多，

因为为什么因为 flutter 本身说能处理像这个 UI 的一些东西， 对于很多核心的东西啊， 比如说你如果说你要做音频视频等等啊， 可能做网络相关的东西， 你可能 flutter 本身其实并不是能够很好的实现， 你可能需要一些还需要去更更底层的一些可能语言去做一些处理， 比如 Rust 啊， 比如 CCGI 之类的。对， 像我这个项目可能大概呃有百分之可能百分之十几到百分之二十大码， 可能还是还是还是 CGI 的 CGI 的 CGI 的， 所以说对于独立开发者来讲的话，

你需要呃熟悉多个多个语言啊， 你不管说是 CGI 也好 Rust 也好， 还是说其他的其他的语言， 就是说你光靠一个 Flutter, 它是很难去做一个呃全平台的这样的一东西的， 对， 但是你如果说产品尤其是这个产品形态比较大的大的时候。

Speaker 1:

嗯， 成员生的开发那些模块可能也跳不过去。

Speaker 2:

哎， 对的， 这个绕不过去的。

Speaker 1:

那为我们的选型点个赞。你看这个这么高的技术力，20% 的代码是 C++，这个在独立开发者里面其实是很少的。可能很多人就是前端就写在 JS，顶多就是 TypeScript。咱们聊了这么长时间这个技术， 咱们从这里面跳出来，咱们聊点商业的事。这个产品上线了一年多的时间，当然也是因为有前面小黄鸟的积累吧，我们有了数十万，现在应该是数十万用户，我这么说是对的吧？

Speaker 2:

对的。

Speaker 1:

数十万用户，那这个我不知道咱方不方便透露一下咱们这个产品的商业化情况，包括这个商业化的路径啊，为了商业化咱做过什么事啊，咱也挺感兴趣的，咱们得聊聊商业。

Speaker 2:

商业化的话其实我对自己的评价其实做的其实做的并不好，当然这个做的不好呢几个原因呢， 第一个原因就是说还是这个产品的整个的重心，重心呢就是说呃， 我其实主要的过去的这一年啊， 主要追求的还是说产品的这个这个用户的增长， 而不是说营收的增长。那为什么为什么我说会有这样一个想法呢？就是这个其实，呃，跟很多人的想法不一样，很多想法可能我产品出来了，产品成熟了，我我需要做的就是说做营收啊啊，其实我的想法就是什么呢？

就是说啊，这个市场这个这个市场呢，这个赛道它是一个很成熟的一个赛道，它是有有非常多的这个啊竞品竞品啊。你要 Postman 也好，或者说其他的等等，包括还有很多非常多的开源项目，你如果说你要跟他们去做一个竞争的话，你虽然说你能够保证这个产品的质量是 OK 的，但是你还是在整个竞争方面你还是会会会没有底气，你的底气会很差。而且你如果再加上一个收费的这个 debuff 的话，这个可能在整个产品的前景会更难。所以我的这个策略呢就是说我尽量的说不去追求营销增长，

也就是说我对整个功能的限制并没有那么的严，就是说整个的从我这边用户反过来其实也是的，就是说他的社区就是说用户都说这个产品的它的社区版足够用了，没有必要去花钱，但是很多用户的心声啊， 所以呢，我这个整个的这个商业化其实说其实还是没有说，就是呃，就是用户的付费率并没有很高，大概可能目前的付费率大概能在 1% 左右，这个其实是很低的数字啊，就是说正常的一个产品，这个这个付费率一般可能知道在 10% 左右吧，呃，我觉得他是一个正常的这个这个产品的一个商业化，所以我觉得这个做的不好。

第一点就是说整个产品的战略，就是说我没有对很多的功能最多限制，用户呢设置版其实正常的用没没什么没什么问题啊，没什么门槛。然后是第一个点， 第二个点就是说呃， 整个的还是说呃， 市场我目前的市场还是在国内 90% 以上的用户都是国内的用户， 然后呢， 国内的用户呢就是呃， 可能很多的用户呢用户呢， 他的一个付费习惯啊， 并可能并也并不是很好。所以所以整整体的这个呃， 付费率不高。对啊， 所以我觉得商业化做的不好也是这个原因。

所以呢就是我的可能后面的整个的呃重心呢可能还是说呃也是说加入出海去这个社区，我希望说在出海这个方面的话能够把这个的产品的商业化营收再提一提。

Speaker 1:

刚才 Megatron 提到了一点， 咱们这个产品商业化付费率比较低，很多产品是因为产品本身做的不太好，咱们这个产品是属于做的太好了，然后免费用户又基本没什么限制，它没有付费版的这种强烈需求了。正好，几位就这个话题，咱们可以聊聊，就是像这么好优秀的产品，它的出海制度，咱们觉得应该是什么样子，包括它现在这个付费模型，可能是有一点点啊，那个过于慷慨。

Speaker 4:

我其实觉得 1% 是一个还比较正常的一个比例，就是一般来说一般产品，我们拿 SaaS 的产品一般 1% 到 5% 都都是可都就我们都见过，我其中是觉得就是说确实如果说你你给免费版或者社区版的功能过于慷慨，那对于这个转化来说就有一个很大的影响，其实是要把这些相对来说比较核心的功能要单独包出来给付费用户来提升这个转化，确实我们过往看所有能把转化力提升上来都是这样的手段，然后另外就是通过重新调整定价来确保一些就是可能现在当前的定价对于一些比较犹豫的用户来说，

他可能需要一些更低的价格或者折扣价格，对。

Speaker 3:

对， 然后包括是不是产品我不知道这个可能要从开发者本人意愿就是比如说是否应该在产品本身里面买一些勾子。这是作为一个付费的入口，不仅仅只是通过比如说我属于有多少个设备量，这些比较整体性。

Speaker 2:

嗯，这个这个对这个就是也是需要考虑的一个地方，也就是说也是我这个呃后面后续的这个工作的这个整个的产品业务的一个重心。就是说呃现在也是一个单单单机单机版的应用，单机版的应用就是后面的整个的包括呃两个点一个点是这个云服务。所谓的就是也是像现在用户的一个比较刚需的一个点。就是说我现在设备很多了，我这些数据呢就是没法同步，我我可能在公司电脑上用了，但是我回家了，我回家在自己电脑上用的时候，我发现这个数据数据。还在工资电脑上，我现在没把工资电脑呢， 同步到我家里的电脑上来，

就是对很多用户也都有这样的问题，所以后面的整个的就是说，可能费用呢，可能包括这个云服务，这个是后面需要去做的，我的预估大概云服务出来之后，付费率应该会有一个比较大的一个提升。这是第一个点，第二个点就是说那个团队协作，因为还是说毕竟它是生产力工具嘛，就是说团队是一个非常重要的一个一个一个点，比如说我的公司好几个同事都在用，然后我这个数据我可能需要分享给别人，或者我有一个工作流，我需要转移给别人的时候，对啊，我我这时候就是说团队协作的时候，其实是一个很重要的一个点，

大家也可能如果也是 QB 的一个必要的一个机对机嘛，那个功能。

Speaker 1:

嗯。鲤鱼在评论时说， KPS 的关键工具，就是那个我们先，他说把 Lens, 把原本免费的功能啊，什么 Logs 啊， 都变成了插件付费的功能。我知道咱们这类的产品其实本身也是有这个插件这种潜力的，当然他可能开发这个插件系统可能费点时间啊，不知道 Megatron 其实有什么这个，对这个有什么想法，这就是一条路。

Speaker 2:

嗯，插件化来说的话，呃，门槛还是门槛还是比较多的，门槛还是比较大的，就是呃，市面上啊，就是说已经做了插件系统的这些东西，一般都做的比较大了。嗯，这个我觉得这个门槛还是还是很高的，就是说我以我目前的这个能力来讲的话，我觉得还是做插件化可能还太早了。

Speaker 4:

对，我想起我们一个老朋友，也是我们之前有采访过的 localbase 团队，localbase 也算是这个开源低代码工具里面比较知名的一套系统了，他们的核心打法就是核心部分是完全开源免费的，然后一些实际场景里面的就是插件是付费的，而且付费的价格不低， 他们通过这种形式来和高性质的客户高需求的客户形成绑定。我觉得这套模式对于想要去做一套比较成熟的又能够快速推动用户增长的这样一套系统是很有用的。

Speaker 2:

嗯，对，然后还有就是 QB,QB 的话是一个提升增长一个很好的一个点啊，就是因为你 QC 的话，你的产品竞价不能太不能太高，而 QB 的话就是很多的真实的服务，其实定价是可以做的高一点的，你的客单价会很会可能会会是 QC 的可能几倍十几倍。

Speaker 1:

嗯。对，那个团队吧，跟这 2b 也是有些联系的吗？

Speaker 2:

对，我想起我之前一个事情，就是之前有一个这个公司找我，对，然后他们想采购，然后我报价之后，因为我现在是没有做 2b 嘛，就是报价还让 2c 的报价去报的，然后，呃，他那个那个公司人他很尴尬，他说你们这个定价太低了，这个还达不到他们报销的条件。

Speaker 1:

你看这这。我刚才想这个事情是因为其他的那些相关的 API 调试工具大多数的路线应该都是云服务，其实对于功能点本身的限制还真的是相对来说没有那么的多，顶多就是我的 workspace 不能有几个。对于走云服务和团队版，包括从自身的经历上说， 我们不说能力吧，经历上来说，也是当前更核心的一个路线。虽然说插件系统它的想象力或者它的发展空间更大， 但插件系统做起来，即便像 Megatron 技术力这么高的独立开发者，可能也是需要一些精力， 花的时间会比较多。

Speaker 3:

对， 然后做企业范， 我觉得可能在这个叙事上稍微有点需要注意的就是， 尤其是我们到时候做出海的话，嗯， 在跟这些海外一些 2B 或者 2 小币沟通的时候， 就人家肯定会比较好奇你的。因为做 2P 的话，人家肯定会需要你提供一些技术支持嘛，他肯定会很好奇你的团队规模，对他技术支持这样一个响应的能力，我觉得这对于一个艺人团队还是挺有挑战的，尤其是从信任度的角度来讲，这样一个开发工具，因为有的时候可能还很重要，就是遇到一些紧急的情况，就怎样把这个用户的信任度给建立起来。

Speaker 1:

诶，有一个话题我之前还跟麦克壮私下聊过，我说这个事咱在直播的时候我想主动提出来，这个是正好也想看看宇诚百分百的意思，咱们这个产品要不要做品牌隔离，至少那个域名把它隔离掉。

Speaker 3:

我在纠结这个问题，刚才我在思考这个问题。

Speaker 1:

因为咱们一般在社区实践里面，还是更偏向于隔离的嘛。

Speaker 4:

其实这个产品我倒觉得没有那么急切的说需要去做隔离，首先这个名字挺好，就是直接会让用户能记住这个名字，然后从品牌上来说，他也非常 branding, 也不会因为开发者是中国人而影响到就是国外用户的使用体验或者感受，因为这个毕竟目前没有涉及到呃，就是数据啊或者隐私的部分，这个还好，不像我们做 sars，做 sars 就特别对这个事情就特别的就看的特别重， 工具化的话，东西其实没有那么重要。但将来比如说你要去做云服务，那这个里面可能就涉及到你要去中国化的部分。

我觉得如果从将来的计划来考虑的话，那重新做隔离是一个前瞻性的打算。

Speaker 1:

我刚才说的这个隔离倒不是说品牌要换，而是把中国版的变成 CNN 域里，国际版的不变，就是相当于把现在官网的中文部分单独起一个网站，我不知道 Megatron 对这个事怎么看。

Speaker 2:

嗯，呃，我其实想法就是说从技术上来讲，先说技术啊，从技术来讲的话，我要问你肯定没什么没什么大问题嘛，就是说你同一个同一个网站的多个云箱部署，这个技术上我想做技术应该都都能够解决啊，但是呢，就是说我考虑了几个点，其他几个点啊，就是第一个呢，就是说这个你所有的这个引流啊之类的，你如果说国内跟国外分开的话，你可能就要做两套两套引流， 比如说你中国用户的这个产品，你需要跳，跳到国外那个这个 CN, 跳到那个 com 站肯定是不行的，你得跳 CN 站，然后你国外的还是国外的用户的话，

你可能就得跳 com 站，不能跳 CN 站，就是说你需要在产品上面可能是做很大的一个区分处理，这个我觉得是还是挺难的，比如说你，比如说你在做一些宣传推广的时候，你需要做不同的域名的中转，这其实还挺挺麻烦的，挺挺不太好的。这是一个点，第二个点就是说，第二个点就是说你，呃，你用户记住如何他能记住你这个东西，因为现在用户呢，可能呃，像一些简单的域名，可能直接带进软件里面，可能直接输入了，你输入的时候，你如果说你呃，一会儿 CNN, 一会儿 COM，你是用户其实也说也很困惑，

你这个东西到底是怎么怎么回事？为什么不能不能搞一套呢？搞一套多好，我只要记一个就可以了。

Speaker 1:

嗯。

Speaker 4:

这个其实不是域名的问题，域名其实是最容易解决的，我觉得这里面核心问题还是你主体的问题，就是将来你要去对外去提供云服务，这里面有数据交换的这个情况的时候，你要对外展示的主体一定不能是一家中国公司，这是肯定的。

Speaker 3:

对，而且即便是从有几个点，我其实也挺纠结的几个人，就比如说这个，因为首先一方面它是一个开发工具，所以说用户的行为习惯不管是国内还是国外还是高度相似的，所以说为什么我们之前有很多很多这个还没有我们推荐他们做隔离很大因素，就是国内跟国外很多对于用户对于产品的期待值跟用户使用习惯差异很大， 会导致你产品本身的这样一个功能， 包括研发路径会有一些越来越多的差异。所以说这种产品做隔离是合理的。像 Reqable 这种产品本身是工具类开发类工具，

就本身全世界开发者对这类工具的使用习惯是高度雷同的， 所以说这个时候拆的话没有必要， 另外一方面就是刚才提到如果我们后面想要积累这样的开发者社区的话，就是做隔离的话会导致这个本身就很宝贵的开发者社区的资源被分割开了，这也是一个不太好的地方，就是可能很多关于技术或者关于产品本身的一些问题，其实比如说这边有人问过，那边搜不到或者是因为什么样的情况，因为这个隔离的原因。但是提到数据， 不光是到时候上云的话， 会涉及到用户数据的问题。

即便是不上云， 当前的状况， 我其实刚才就在纠结这个事情。我们到时候要接触海外的公司。它如果是要在内网上跑这些 request 的话，这些数据的话还是带有隐秘的，因为它涉及到公司的一些机密数据或者隐秘数据吧，因为你做 API 测试，这些数据它不敢保证都是脱明的，这是多多少少是会设计，即便你不上云是一个本地的工具，对吧，你怎样保证它这个对啊，人家人家是否会有个担忧，后面有一些数据劫持啊，或者怎样数据记录啊， backlog 这些问题。

Speaker 2:

嗯，嗯，对的，这个这个我之前也是有深刻深刻体会的呀，以前那个做那个小黄鸟的时候也是的，因为他有很多也是国外用国外开发者嘛，他会就是怀疑你这个，比如说因为呃，你这个工具其实是中国的工具，然后他会很紧张，他会去可能会通过一些其他的工具，再去分析你这个，你这个，你这个软件本身他是不是有没有一些恶意的行为，比如说你这个数据有没有上传到这个中国去等等，其实都会有，然后因为我当时是这样的，当时呢，我的 bug 呢，那个 bug 上报是用的那个腾讯的 bug 里。

他的数据包是发送到腾讯的服务器的，然后国外的这个开发者就就扒出来说你这个产品在偷偷的这个向中国的境内的服务器发送数据，然后他这个发送的这个 IP 是什么，然后这个然后查到这个 IP 是腾讯的 IP, 然后然后就是大概可能在一些某些网站上，然后然后会发出来说这个软件可能不安全等等，就是说还是很影响这个产品本身的口碑跟对的。

Speaker 1:

这个问题是得注意。

Speaker 3:

说到这一点，国外有没有一些第三方的这种软件的安全性分析的这些，这还真是在我的知识范围内，不知道大家平时有没有接触过，就是国外有没有这些第三方，风力第三方做安全测试，安全评估的这样一些公司啊，机构。

Speaker 2:

有些网站就是说你的用户，比如说你可以把你这个软件上传到那个网站，那个网站会把你分析出来，然后你这个里面用到了可能会有些，比如说有风险的一些地方。哦，你不是说的那个吗？

Speaker 1:

把那包分析一下有没有风险。免费的。

Speaker 3:

对，因为我们都是。我插句话，我以前专业学信息安全，其实是有专门那套分析的框架的，甚至是你说都不需要你把这个原代码提交上去，哪怕这个已经编译过了，它也是能通过这种测试能帮你，配合测试也是能帮你这个安全性，至少安全性一定程度上测出来。我的意思是说，我需要这一些做出海的手机，这些开发工具涉及到一些公司敏感数据的， 有这样一个背书会好一些，所以到时候找，现在这个事情有点，呃，一时半会讨论不清楚，我看回头我们看能不能找一下，然后做一个安全信用背书吧，这样子会好。

Speaker 4:

对，或者我们三度开一期来讨论这个。

Speaker 3:

嗯，对。

Speaker 1:

我确实看到有一些比较大的产品，包括下面加上几个 badge, 就是我经过了什么什么认证，但这个对于咱们这个体量来说，能够去做这些事情，可能还是需要再讨论一下。我 callback 一个话题， 两位这也是我们 BitFold 的见习成员。所以说这个 2B 有些采购不能便宜， 比如一些回购什么的呀。所以现在国内很多的 2B 产品， 它不会直接在网站上把价格写出来，而是写着敛济客服， 咱们再讨论讨论这里面的事儿。所以你把 2C 的价格直接报出去， 可能对方一听这么低，我怎么报呢？

我怎么去吃这个单呢？

Speaker 4:

国外不知道有没有这个事儿，这个我还真不清楚也有也有，但大多数情况下他都会先抛出一个就基础价格除非是那种 agency 的服务他可能会写单独联系客服就联系去定制然后，哦是，那你们那个直接团队办的价格吗。

Speaker 5:

说到这个啊，就是我有一个东西想问一下那个就是我看那个企业版的那个定价反而比个人版的更便宜，这个是怎么考虑的？

Speaker 1:

一辆的意思吗？

Speaker 5:

哎，其实这个定价就是我我看我第一眼看到就很奇怪啊。

Speaker 2:

是这样的，就是因为企业版其实没做起来，就是说当时，呃，随手加上去的加上去的那个东西，当时企业版也一般也没有人买啊，一般都是都是买专业版，基本没有人买啊，放上去的那个原因呢，主要是这个当时想过去做 QC，比如说这个 QC 嘛，就是可能一般可能采购量会比较大，一般可能可能都是几十单。对吧，几十个席位就够买，几十个席位就够买的话，就是说对，然后但实际上并没有人，并没有人去买啊，可能是个别的，可能会买个两三席的这种比较多，然后买个几十席的基本上没有。

对，然后这个定价呢，所以这个定价也比较随意，然后呢，因为我想当时想的是个人版，个人版的设备会比较多，会多一点，多一点就贵一点，然后企业版的话就是设备的支持的授权的数量少一点，所以价格也就便宜一点。

Speaker 1:

但是从波波的反馈，或者说从波波这样的用户反馈来看，有点奇怪，怎么比这个人版还便宜，感觉好像要贵一点。

Speaker 2:

嗯，这个其实是个很很失败的，很很失败的，这个这个这个处理啊。

Speaker 1:

定价模型啊，也是咱们孵化这个例会当中很重要的一环，会有一节去讲这个。德木也说这个企业反量大，但是从刚才 Megatron 的回复回复来说，应该是拍脑门想的。

Speaker 3:

哎。

Speaker 1:

嗯，咱们还有最后一话题，这个话题是我主动想提的，也是想听听宇诚摆上勃勃的意思。我特地去看了一下 Megatron 的推特的数据，嗯，我还专门私下跟他聊过这个事。Megatron 呢，他现在不运营推特，原因是啥呢？发了 4 条因为推，没有什么水花，下干了。

Speaker 3:

啊，啊，啊，这个标准，标准误区。

Speaker 1:

嗯， 啊，他推特就是产品名字啊，Reqable, add Reqable。

Speaker 3:

嗯，OK，这又是个纠结的点，我起个头吧，两个事情，两个话题，首先第一就是到底是做个人，先做个人，然后还是先做产品好，嗯，不太建议一起做，因为非常分散经历，就小团队，艺人团队带不动，但是呢，如果从里面挑一个先做哪个的问题，这个原则上来讲，我还是推荐先做个人号，但是呢，Reqable 它这个产品有这个比较特殊的情况，所以说拿不定主意，得思考一下。

Speaker 4:

我其实觉得我有，我觉得有个对标的账号，就是国内的数码荔枝，虽然不是同一个类型的，但是我觉得可以往这个方向去靠一靠，就是它其实是一个以个人号的形式在做产品号，就是你去看他所有的发言，本质上来说呢他是一个以个人观点发出来的，但他的账号呢确实是一个品牌账号，这个方式我觉得是 OK 的，就是首先这个你可以通过这样的方式把你的个人和产品进行强行就是高强度的关联， 这个是一个我觉得是一个怎么说呢其实是通过你个人形式带动起来的，

大家都知道你是 Reqable 的创始人开发者， 就可以了， 绑定在一起， 对。

Speaker 1:

而且个人 style 它有一个好处，就是它会有一个鲜活感，这个是品牌这种，如果纯品牌的一个对外宣传的渠道所不具备的，于诚，然后第二个点就是刚才我想说第二点就是是标准误区吗？

Speaker 3:

就是冷启动的时候上来发发推推文没反应，然后就讲错了，因为至少你在先把来一个 follower 之前不要发推文，不要单独发推文，或者你可以发，但是你不要指望有更多的 engagement, 一开始至少一千以内的话，其实更多是来自于你跟社区成员的互动，所以说利用这个机会去起心头的时候，利用这个机会去结识应推上的可能是你未来潜在社区成员的这些画像， 你不管是你通过搜关键词， 还是什么用其他的一些相关竞品的官网下面看他的 follower 都有谁，

然后你去 follow 一下他们，看他们平时发什么文章，然后你尤其是什么呢？尤其是他们如果有一些问题或者难点在推特上求助，对吧？你刚好看到如果自己能解答的话，你去他们留言给他们帮助。对，就一开始其实填一千个 followers, 绝大部分都是来自于这种渠道，不是说你发推文，人家看到。嗯， 来这儿孵的话， 得统战。嗯。

Speaker 1:

关键是 Megatron 可能没时间，因为它本身要去做这么，因为这是一个技术壁垒比较强的产品，再加上它现在每天有很多时间去处理一些 feedback, 这就为啥我刚才提这 feedback 的时候特地提这个事儿，就能不能用 AI 帮你解决一些，因为如果是精力分配的话，这个技术啊，首先不可能外包，也没法外包这个事情，那我还是更希望去做这个设媒的增长，而不是把精力花在去。

Speaker 3:

就是这两件事情你是不能外包嘛，首先第一就是产品本身，尤其是核心部分，第二就是用户沟通嘛，但是在这里的话就是可能也是听麦克松你的意见，就是可能尤其是你现在要做出海的话，你这个产品跟用户的这个触达可能是你当前阶段需要多允许一些时间过来，就如果你要调配这个资源分配比例的话， 这个块你可能会需要每天多调一些时间过来，其他的话我们看看能不能想办法，就尽量能分出去就分出去。

Speaker 1:

而且这个平 A 的产品是国内外是它的用户画像几乎是一致的，用户使用习惯也几乎是一致的，就是这个产品本身出海产品本身来说是。没有什么需要去说啊，很我们很多产品说我要去看一下北美人的这个用户需求是什么啊，欧洲人的用户需求是什么啊？他们对于这个产品我都会能不能把握好他们的这些呃想法什么的。但是像咱们这个产品是不存在这个问题的，直接这个产推到美国用户面前，他也知道该怎么用。所以这个时候呃，如何让他们知道有我们这个好产品。就包括设备增长吗？

我个人认为可能会更重要一点，但是现在确实麦克穿把这个就是被这个海量的 feedback 给占据了大量的时间。

Speaker 2:

嗯，这个是后面肯定是要搜，我觉得肯定是要搜集掉一部分的，就是尤其说在这个，当然我现在的这个很多的这个 feedback 的处理，就是说呃，一般现在还是处理一些付费用户的这个 feedback 的。对， 这也是后期的后期整个的说整个的需要搜集掉的一部分， 就是说可能社区版的用户的 feedback 可能就呃， 回复啊之类的处理基本上没那么及时了， 可能对， 可能会会每天或者说没几天凑一半时间去做去处理， 这个也是后面做的。

因为毕竟早期嘛， 早期产品的功能各个缺陷会比较多， 现在还是基本上是所有的造色不误， 那后面就是说。做出海的话，国内的很多的就是可能只处理付费用的，然后社区的就就先放一放。然后呢，就是呃，在社媒这个方面的话，确实就是刚刚那个雨晨说的就是，呃，也是也那可能也是很多很多这种人的这个典型的这个能启动方面的误区吧，就是呃，发了几条推文就后面就就不发了，对，因为还是就是说，嗯，当然还是还是方式不对吧，就是呃，因为光靠自然流量的话，你发出去推文确实不会有多少的这个爆点的，这个很难的。

你要么还是说起大量的用户，就是就是大量的粉丝，这样这样呢会会比较好一点，对，然后呢我呃，包括很多的就是呃一些嗯竞品啊竞品的这些这些就是这些粉丝的这个触达，我觉得这倒是我之前没想到的一个一个方面啊，就是确实是一个很很好的一个渠道，就是能够你能够知道他们的一个状态，他们所需要的他们面临那些问题。对，然后你的产品呢，是否具备的可替代性，是否具备这个可解决性，就是能够能够在第一线触打他们，这个我觉得还挺有可操作性的。

Speaker 1:

像这个产品，这 Hacknews 和 Reddit，虽然这俩平台不好运作，但确实还是挺合适的，因为咱们这个产品，尤其是 Hacknews 上面。

Speaker 2:

Reddit 我的号被禁了，对，然后也没发也没发几个 post，对，然后因为对，因为国外对这个整个的软管还是比较抵制的，基本上可能就过不了系统程度那一关。

Speaker 3:

就是说带了产品链接是吗？带了产品推荐链接那种。

Speaker 4:

应该是你广告太硬了。

Speaker 1:

稍软一点。

Speaker 2:

我之前的那个方式是这样的，我之前方式呢，是在那个 medium 上面写一些技术上面的文章。对，然后呢，在 Reddit 把技术文章引过去，然后技术文章里面再引的这个产品。对呀，但是发现还是不行。

Speaker 4:

对，你会看他一般的 subreddit 里面的板规是会要求不能带 promotion 的内容，就是或者是连 blog 的内容也不能带，那我们通常会用这个问问题，然后自问自答的方式来去做完软广告。

Speaker 1:

自文自答。

Speaker 3:

对，对。就类似于。

Speaker 1:

解决啊，宇峥先生。

Speaker 3:

我就说就类似于如果要软广的话，就说有没有市场上没有就整合，比如说 Postman 加什么什么加什么什么。这些功能在一起的，我不想单独下，每个三个都单独下，对吧？然后你就可以下面换一个账号跟上去，贴个软管。

Speaker 1:

嗯，对。

Speaker 3:

其实也是 SU 的打法。

Speaker 2:

嗯，我是考虑过几个，但是你会发现在这上面呢，关于这个整个的就是 Postman 啊，技术上面的话题很少，非常的少。对,非常的少。然后比如说我还尝试过说在这个 flutter 社区里面，因为 flutter 社区里面它会经常会遇到很多问题啊，就是用户说啊，哎，我这个遇到什么问题，对，我可能会我会可能回答他说这个问题可以怎么解决，然后然后用用什么东西，然后你可以参考这个这个这个我的这个产品怎么怎么样，对，我会这样去做这个引流，这个效果还可以，这个效果还可以。

Speaker 1:

我刚才就在想，咱们把 Flutter 这边关于文本编辑这么难的部分都给攻克了，那这里面的技术，我们能不能写一些文章，或者写一些技术文章，一组文章？

Speaker 2:

有，我其实这个是写了国内的，没有写国外的。

Speaker 1:

写国外的，发到 Hacker News 上面，这个东西也不是什么，就是你看我，我解决了一个技术，对不对，很难解决了，我不想出来，然后呢这个。

Speaker 3:

It's a government building, probably.

Speaker 2:

这个这个一直没时间去做完，这个其实，呃，之前有很多朋友也建议过说这个把这个我这个国内的这些博客，然后翻译成英文发到 IndiaHacker 之类的上面去，他们觉得这个一定会爆，可以。对，这个可能，这个也是后面的人需要去做的。

Speaker 3:

好多事情。

Speaker 1:

李唐也说，medium 也要发一下。我们评论区。

Speaker 4:

下次我们得邀请，邀请首富来跟我们做一下分享的。今天撞到他了啊。

Speaker 1:

你看我就老是感觉吧， Megatron 有很多事情都可以做，我为什么一直强调他在我心中是高阶的独立开发者，但是高阶的人呢，可能做的事太多了，导致他没有时间去做这些事情。特别增长这个事要起，一些像 reddit 或者平台上面一些宣传这个事情也得做，甚至说咱们出海之后可能需要把精力还是更多的要放在这种宣传或增长上面，因为产品本身是比较完善的了，嗯，可能稍微定价这块稍微需要一些工作，对， 定价这块， 点下来的时候就往上涨， 当然也要对标这个， 这个这要看一下竞品啊， 嗯，

海外的付费习惯还比较好一点， 反正两阶我的建议是这样， 反正两阶段嘛， 就第一阶段我们先先就不考虑那个云了， 因为那个可能对于。

Speaker 3:

产品本身还要迭代一段时间，可能对于对你个人而言有一些比较良好的正向反馈会对你未来就鼓励你继续再把这个事情往下做的话，可能就是早期能获得一些真正的海外付费用户，就一个比较好，不管量多量少吧，就是一个正常反馈，至少证明这条路可以走，然后再去考虑这个接下来这些做得更大的， 比如云服务啊， 做 2B 啊这些， 真正影响 2B 啊， 一开始的时候可以按照 2C 的玩法，然后 SEO 的玩法， Building public, 品牌构建， 社媒增长， 只标准打法来做荔枝端子。

Speaker 1:

Megatron 也是我们 Betfor 的成员，所以这些事呢，具体的过程，咱们也可以在孵化器的时候一步步去推进。来，现场的观众朋友们，我们给 Megatron 和 Reqable 来点赞。感谢大家今天接受我们的邀请，跟我们分享了这么多的历程。

Speaker 2:

啊，谢谢，谢谢大家，然后感谢出海去。

Speaker 4:

哎，我发现一个有意思的事情啊，就是这个 Reqable 的中文名字，你们猜叫什么？我刚发现了，非常有意思。

Speaker 1:

刚才他说了一点，我说啊，是吗？

Speaker 4:

日夸宝。非常好啊。

Speaker 1:

但是好像我这个名字大家用的也不多，嗯，感觉像做金融的，是有点。我们给 Megatron 点赞。好了，说一下关于第四期孵化的事儿。本院还是在第四期孵化的间隙期。如果大家想加入孵化的话，现在还是可以申请的。Megatron 就是我们的孵化成员。我们也希望这个产品能在海外发展得很好。这样你进来之后就跟 Megatron 属于校友，平时在这里就可以多聊会儿，然后电完会也会有例会。

Speaker 4:

阿白问，首富什么时候上场？我今天下会之后就去邀请一下首富。

Speaker 1:

这个话题咱们可以在群里聊。今天的嘉宾是 Megatron。那今天呢我们也聊这么多吧， 又没聊一半小时吗？感谢 Megatron 给我们分享了这个新的历程。这个产品呢是我们很喜欢的一个产品， 它是很成熟的，也是很， 我怎么讲这个。在独立开发者的产品里面，他做的这个产品本身应该说是在我心目中，我看了这么多，这些产品应该是非常无论是技术力还是产品力都是算强的一战。对于说阿白说今天没有讨论税务问题，是因为现在跟 Megatron 还没有遇到太多的税务问题。

我们可以接下来讨论下一期或下一期的讨论。我们今天主要讨论的是整个新闻历程或者是这个出海之路。放心，这个产品的出海，我们一定会讨论这个数据问题的，就是今天这一次没有讨论，我们可以关注接下来的，我们每周五都会有固定的直播，这个不能着急啊。哦，还有，你可以加入我们的会员吗？因为这个名字，就现场大家的名字跟在社区里的名字不一定一致，所以不太好判断咱们是不是会员。如果你已经是会员的情况下，我们可以在大群里去讨论税务问题。

这个问题也是，呃，包括收款，包括税务，包括怎么开公司，是群里经久不衰的话题。

Speaker 3:

嗯，日常问题啊，日经问题。

Speaker 1:

嗯，所以你一定会能得到大家反馈的。那好，今天呢，咱们的直播到这也就今天为上了。非常感谢 Megatron 接受我们的邀请。大家也继续支持 Reqable 这个产品。感谢 Megatron 的参加，也感谢大家的参加。

Speaker 2:

感谢大家。

Speaker 1:

好，那咱们就跟大家说拜拜，握个手。拜拜。