Retool：重塑现代企业的 1/3，为SaaS装上乐高底座 - 元宇宙 - 元宇宙

网站首页 >> 元宇宙 >> 正文

简介：作者：NCL 编辑：penny 排版：Bonnie、Lydia 繁荣的 SaaS 生态下，仍然会有大量的长尾需求无法被提取成可复用的产品，

作者：NCL

编辑：penny

排版：Bonnie、Lydia

繁荣的 SaaS 生态下，仍然会有大量的长尾需求无法被提取成可复用的产品，公司不得不让内部的 IT 人员负责花 1/3 的时间开发这些定制化工具。既然需求是没法标准化的，Retool 提出就用低代码标准化开发工具，为技术人员提高开发和运维效率。

内部工具开发是一个规模可观的市场，不仅成熟的 CRM，EPR 市场仍有大量的非标需求，并且科技新贵 Stripe、Plaid 也因复杂的业务需要高效开发。我们预估内部工具开发的美国市场 TAM 在 200 亿美金左右，未来会随着渗透率提高和国际化有较大增长空间。

Retool 是内部工具低代码开发的先发者和定义者，在尊重原创精神的硅谷已形成品牌壁垒。通过多年打磨，Retool 的产品已在 UI、后端和前端的功能覆盖上比较完备，让竞品难以抢夺市场。也积累下各个行业客户资源，不仅有 Stripe 等科技新贵，也有奔驰等传统巨头。2020 年到 2022 年，Retool 的 ARR 从 1000 万美金增长到 8200 万美元，增速明显快于早期的 Airtable 和 Zapier 等公司。

Retool 的团队奉行长期主义：在公司早期耐心的听取客户需求和建议，及时调整产品迭代方向；融资策略也是主动压低估值和融资额，通过让员工的期权利益最大化来吸引人才；公司的财务情况健康，多年持续盈利，以目前的 Burn Rate 来看，账上现金能持续二十年。

我们认为 Retool 是一家值得关注的公司。其所在的行业规模可观，利润率较高，而渗透率仍在早期，有高速增长的潜力；作为一个高客户黏性行业的先发者和定义者，已形成了产品、客户和品牌壁垒；公司也有着长期主义的团队和增长策略，优秀的财务情况让公司能维持数十年可持续发展。

以下为本文目录，建议结合要点进行针对性阅读。

01 什么是内部工具？

02 什么是 Retool？

03 增长策略：客户、产品、信任

04 团队：长期主义

05 竞争：开源和无代码

06 壁垒和局限

07 业绩与估值

08 结论

01.

什么是内部工具？

内部工具指的是面向公司/团队内部所开发的软件。通常企业需要搭建数据库来存储订单、客户或系统报错信息，而客服或运维人员需要高效地获得最相关的数据，并需要做出删改，企业内部工具就是中间的润滑剂。

比如 Plaid 的早期客服人员 Chris O'Neill 分享了客服团队最常见的内部工具场景，他们需要先后调用 Zendesk、Jira、Slack 和各种内部数据库来解决客户遇到的 Plaid Integration 服务宕机的问题。他制作了一个后台管理面板，帮助团队在同一个界面内完成多个数据源增删改查，提高员工效率。

除了上面的后台管理面板，常见的内部工具还有：客户 CRM、销售 ERP、数据库 GUI、库存管理 App 等基于数据库或 SaaS API 的企业工具。尽管 CRM 和 ERP 都有现成的方案（如 Salesforce 和 Hubspot），但这类产品只会提取出能标准化的需求，将其做成一个大量公司可复用的平台化产品。

在实际操作中，各个公司的客户关系管理流程不同，会有很多定制化的长尾需求，大平台不太愿意为了不到百万美元的订单指派一个团队去做这类无法复用的功能，这时各个公司只能让自己的技术团队搭建这些“用钱买不到”的功能。这样的情况在 ERP、数据库、库存管理 App 都很常见，内部工具就在解决各类 SaaS 无法满足的长尾需求。

综上所述，内部工具不仅是企业 SaaS 之间的润滑剂，更是解决了各类 SaaS 无法满足的长尾需求。

内部工具的需求

现代大部分企业都采用内部工具，金融服务企业是最多使用内部工具的。根据 Retool 的市场调研，多半的金融，科技和媒体企业都会使用内部工具。而在公司内部，运营、客服和营销这三个现代企业几乎都有的部门恰好是最需要内部工具的，近 55.4% 的受访者表示他们需要为公司的运营团队开发工具。

企业内部技术团队需要将 1/3 的时间用来开发、维护内部工具，并且越大的企业对内部工具的需求越强烈。Retool 报告的2285位受访者主要是全栈工程师、产品经理和公司联创，他们表示平时需要将 1/3 的时间花在建造、维护内部工具上。此外，企业的规模和其内部执行效率成反比，因为内部跨部门协作的摩擦更明显，也更需要内部工具来优化工作流，所以调查显示，千人以上的团队甚至需要技术部门花 1/2 的时间在内部工具上。

内部工具的“现代化”

而随着 SaaS 行业和数据库行业的繁荣，现代企业内部数据来源也极为多样：大部分企业或多或少都需要工具来快速调用、查询内部的数据库，也有近半的企业会整合内部或第三方 API 来丰富工作流。

更具体来说，尽管 PostgreSQL、MySQL和 MongoDB 是最主流的数据库类型，但单个企业也会根据需求调用多种数据库来满足不同场景。比如采用 MySQL 来存放一些邮件模板从而降低部署复杂度，而需要存储和查询巨量数据时采用 MongoDB。除此之外，随着 SaaS 的兴起，云服务上的数据调用也逐渐变得至关重要，所以内部工具也要支持多样的第三方API，尤其是需要支持 Github、Slack 等当代企业深度整合的产品。

内部工具的市场规模

在 Retool 出现之前，企业的内部工具主要是通过指派全栈工程师团队搭建的，他们通常采用开源框架和语言搭建这些高度定制化的工具。比如，用 React 或 Vue 搭建前端界面，用 jQuery 或 Express 作为后端访问数据库或是 SaaS API 的请求工具。换言之，先前并不存在这样完整的开发工具，也就没有直接能够参考的市场空间。我们接下来通过 Bottom-up 的方式估算 Retool 的潜在市场空间。

Bottom-up

通过参考 Retool 对不同员工规模公司的内部工具团队薪资估计，Bottom-up 估算 Retool 将能为不同规模的公司减少多少成本。

· 假设 1：一个软件工程师的平均年薪为 $106,000，以每年总工时为 2100 小时计算，对应着 $50/小时。(Glassdoor 数据)

· 假设 2：每个公司有 10% 的人负责软件开发和维护，这是主观数据。

· 假设 3：平均一个软件工程师花 20-30% 左右的总工时在开发维护内部工具上，这跟公司规模挂钩。(Retool 报告)

· 假设 4：根据 Retool 博客的案例分享，采用 Retool 的工程师有25-75%的效率提升。这里保守假设 Retool 为公司节省了 1/4 的人力。

· 假设 5：不同雇员规模的公司数量来自 NAICS 的数据。此外根据 Stistical Atlas 数据，约有 1/3 的美国公司跟管理、金融、营销和 IT 有关，这些公司通常需要内部工具。

因此，内部工具开发的美国市场规模大致在 200 亿美元左右，假设美国市场占全球市场的 1/3，那么全球内部工具开发市场规模大概在 600 亿美元左右。Retool 当前的渗透率在 0.4% 左右，想要成长为 10 亿 ARR 的公司需要将渗透率提升至 5% 左右。这还不包括未来软件工程师的工资上涨和产品迭代后的效率提升，TAM 也有很大的增长空间。

02.

什么是 Retool？

既然需求是无法标准化的，那么就标准化这些长尾需求的开发工具，Retool 以低代码的方式提高内部工具开发效率。

传统内部工具开发流程可以分为数据库搭建、后端代码、前端代码和运营迭代四大步骤，而 Retool 则通过低代码的方案来解决每一步存在的问题。具体来说：

1. 数据库搭建

Retool Database 将帮助非技术人员搭建轻量数据库。

Retool 近期新增了 Retool Database 产品，由 Retool 的云服务器来运行 PostgreSQL。这条产品线比较类似 Airtable，适合没有过高性能要求或没有技术背景的团队快速搭建轻量数据库。这些轻量数据库可以跟团队主要的 self-host 数据库结合使用，搭建独特的工具。比如，不懂怎么搭建运维数据库的客服人员可以自己导出一个轻量数据库存储自己负责的客户 CRM，从而不需要麻烦技术人员。

但这条产品线预计不会是 Retool 的主打功能，只是为了满足业务流程中的小需求而存在。

2. 后端

Retool 将帮助开发者高效请求数种数据库和 SaaS API，并支持高自由度的数据格式转换。

传统内部工具后端的主要问题是学习成本高和部署步骤的繁琐。前文提到内部工具的现代化趋势，企业内部通常有多种数据库和 SaaS，这将需要开发者学习多款数据库和 API 的开发文档。此外，由于数据来源的多样化，导致请求数据的服务器和数据来源之间的关系错综复杂，这需要大量的时间整理服务器之间的调用关系，且让未来维护迭代的工作异常繁琐。

Retool 支持多款数据库和 API 的请求。它不仅支持多达 19 种数据库（如 Snowflake 、MongoDB 等）的增删查改，而且也支持 20 款企业常用 SaaS 的 API。比如用户可以从 MongoDB 读数据，插入到来自 PostgresSQL 的表，将结果经过处理后发送给 Stripe API。

Retool 保留了数据格式处理的自由度。它允许开发者在几乎所有地方使用 Javascript 来保证灵活的数据处理，并且内置的Transformers 可以批量进行数据格式转换，保证最大限度的可定制化和最合理的呈现效果。

Retool 帮助开发者高效部署数据请求工具，弱化调用关系的复杂度。开发者以往需要设置多台服务器来访问数据来源，当需要进行跨来源请求时，数据在各个来源的位置关系是让开发者最头疼的地方。Retool 则弱化了位置关系的重要性，开发者可以在几乎不知道哪台服务器正在请求的情况下直接使用数据，节省了位置梳理的时间。

3. 前端

Retool 帮助开发者拖拽生成丰富的前端组件，灵活生成操作面板和工作流。

传统内部工具开发在前端的主要问题是工程量大和高重复度的问题。比较常见的前端界面由各种表格、问卷、可视化图表等组件组成，连最简单显示三四列表格都需要近四五十行代码。尽管技术难度很低，但不可否认的是开发者需要大量地复制粘贴模版代码来完成工程搭建。

Retool 通过低代码的模版和拖拽生成来提高开发者的效率。首先，Retool 内置表格、问卷、可视化图表、富文本编辑器和地图等 90 多种前端组件，几乎覆盖了所有前端需求。当开发者搭建过程中，省去大量学习和定制组件的时间成本，仅需拖拽就可灵活设计，Retool 称这能为开发者一周省下 5 小时的工程量。

Retool 允许两种前端展示形式，一种是传统内部工具中常用的操作面板，另一种是最近推出的工作流。

· 操作面板：将各个数据来源统一放在一个界面里，减少在应用之间切换的磨损。

· 工作流：用户可以根据先前开发的流程高效地完成工作，或在某个条件下会触发一系列的流程。比如下图中，Retool 设置了一个每天中午总结销售数据发送给员工 Slack 的工作流，跟 Zapier 类似。

4. 运维迭代

内部工具的运营迭代成本占总成本的75%，提高运维迭代效率将对开发团队的效率提升最大。当前运营迭代的成本是被严重低估的：根据 Glorath 和 Schach 的研究，软件的运维成本大概是总成本的65-75%。具体来说，根据 Internal.io 报告，运维成本中大概有 20% 是修复 Bug 的成本，25% 会是维护成本（更新数据源、用户界面、权限管理），剩下的则是迭代成本（增添功能）。

传统内部工具开发的痛点在开发逻辑难以继承、部署迭代步骤繁琐。比如在双十一期间，淘宝内部会开发临时给运营人员开发的小工具：尽管只用一两天，但却需要几天时间开发，因为既要考虑到迭代扩展问题，也要考虑权限管理和资源监控；而到第二年小工具却因为数据源上的小改动或开发人员的调离导致无法复用，新负责的团队只能从零起步再次造轮子。

Retool 则将权限管理、资源监控、迭代扩展工具打包，开发者不再需要在开发新工具时多次重复造轮子。对于任何一个新内部工具界面，以上的常用功能都直接 built-in，从而节省大量时间。此外，Retool 允许开发者能够部署在自己的服务器上，满足数据极致安全的需求。

03.

增长策略：

客户、产品、信任

以客户为向导

Retool 通过听取客户建议后，在内部工具赛道找到了 Product-Market Fit。

Retool 诞生时并不是想做好内部工具，而是想改变软件的构建方式。换言之，Retool 当时想做的只是当时火热但模糊的低代码软件，当时也被叫做可视化编程语言。但这个拥挤的赛道中，从 YC 刚毕业的 Retool 难以真正找到 Product-Market Fit。

和大多数初创企业不同的是，Retool 从 YC 毕业后既没有选择增加销售团队来快速扩张市场，也没有选择扩张工程团队打磨产品，而是 CEO David Hsu 带领大部分成员（据说当时10个人都不到）发邮件寻找潜在客户。比如， Hsu 花了几天给 FileMaker（一个苹果旗下的数据库低代码软件，有着数十年历史）的 Linkedin 群中的300 多人发了邮件，只有三封回复，内容都是 Retool 的路径有多么糟糕。Hsu 回忆那段日子庆幸地说，幸好当时在 YC 听了很多毕业三个月就濒临现金流断裂的例子，他们毕业后完全没新招人，谨慎扩张的策略保证他们熬过了早期。

转折点发生在2018年8月， Hsu 在 YC 的 Hacker News 的帖子中表示，通过和客户密切交流后，将公司的方向从可视化编程工具转向高效打造内部工具。这个帖子中很多的建议，比如允许 Self-Host、Slack Bot API、企业登陆管理等功能，Hsu 在积极回复后，调动团队完善这些工具。

WebLink:

https://news.ycombinator.com/item?id=17725966

正是以客户为向导的理念，使得 Retool 在初期能够规避埋头打磨产品或用巨资投入销售扩张，让珍贵的资金支持团队成功找到 Product-Market Fit。此外，和用户密切沟通需求的方式也延续至今，在 Retool 的博客中有大量用户的调研和使用方案分享，这都有助于社区和团队的密切交流。

PLG + SLG

Retool 从定价策略上来说是典型的 PLG 策略，主要有明确的三种套餐：Free、Team 和 Business。Free 套餐已让用户近乎完整的体验功能，鼓励它们自下而上地驱动所在的团队甚至整个公司采用。而当工具在内部扩散开后，对权限和版本的控制需求将自然地驱使用户开始付费。具体来说：

· Free - $0/user/month

免费套餐允许用户连接所有的数据库和 API ，尽可能地吸引用户来尝试 Retool，看是否能满足办公需求。但用户上限低和简陋地权限管理，使得团队协作时较易遇到瓶颈，鼓励他们升级成付费套餐。

· Team - $10/user/month

团队套餐提供了完整的权限管理工具，也允许无限扩展使用人数。除此之外，还增加了版本控制和测试环境等功能，从而能够保证不影响团队使用的情况下进行开发和迭代。

· Business - $50/user/month

Business 套餐则通过增加 Module 数量吸引资深用户升级。Module 是用户已经开发好的前端组件，比如上面 Plaid 的后端代码管理界面。这种组件开发时需要对数据库和 API 进行大量的数据预处理，所以能将这些数十个小时的开发时间打包，直接复制到另一个界面，将能大量的节省内部工具开发者时间。所以团队套餐的 Module 上限是5个，而 Business 套餐则取消了上限限制，最大地节省开发者的精力。

但在 Retool 内部，除了工程团队外，人数第二多的是 Sales Team。因为当一线员工用 Free Plan 上手后，Sales Team 可以快速对接，为他们提供定制化的套餐。比如 Brex 和 Doordash 这类因重运营严重依赖内部工具的公司，他们愿意尝试各种内部工具开发的新产品，这时候 Retool 的 Sales Team 早点进行对接有助于在公司早期就建立深厚的合作关系，他们现在也是 Retool 最大的客户之一。

从 Retool 公布的客户群体上看，客户主要分布在五大行业，既有科技新贵，也有老牌传统巨头，说明内部工具的变革不仅发生在新经济驱动者上，也正在改革既有格局。

Raise for Trust / 为信任而融资

Retool 并不差钱。

根据 Scara 数据，他们在2022年11月时预估 Retool 的 2022 ARR 将能达到 8200 万美元。但 Retool 还是从资本市场上先后进行了5轮融资，从中获得了1.4亿美元。此外，其实 Retool 几乎从创办开始就一直都在赚钱：2018年开始就已经有25个主要客户，ARR 为 50 万美元。所以其 CEO 在 Podcast 中透露，在 Seed 到 A 轮中，Retool 基本只烧了20万美元，在 A 轮到 B 轮中，只烧了50万美元，这仅占其累计融资额的一小部分。这意味着 Retool 有着极其健康的 Burn Rate，将毫无疑问能撑过可能将要到来的大萧条。据近期面试过 Retool 的人透露，他们团队的现金至少能够支持二三十年。

而 Retool 多次进行巨额融资的真正原因是：Raise for Trust。Retool 在2020年就有一个拥有十万名员工的巨型客户，每年愿意花4亿美元在内部工具上。但做内部工具的平台需要信任才能得到这种大公司的订单，因为当客户每年将大量资源投入在内部工具上后，希望这个平台能够长久存在，从而避免再次从零搭建。尽管 Retool 的财务情况很健康，但在大客户心里也比不上上百亿市值大公司，所以 Retool 需要进行几轮融资来保证估值的健康增长，塑造能长期服务的形象。也就是说，Retool 募资并不是为了营销或研发经费来扩张，而是通过增强可靠感来吸引大客户，完成扩张。

04.

团队：长期主义

创始人 David Hsu 在牛津的哲学和计算机专业完成本科。读书期间曾创办了 Cashew，一个牛津学生在校内用的支付和转账 APP。Hsu 最大的特点就是低调、热情和谨慎：

· 低调：Hsu 几乎不在社交媒体或私人博客发言，也不太参加当前流行的 Podcast。

· 热情：他经常会主动发邮件给客户并倾听建议，不少客户收到 Hsu 的邮件后感觉完全不是一键群发，所以通常饶有兴致的回复自己的需求。

· 谨慎：在公司成立初期，不急于扩张销售或研发团队，而是耐心的了解客户需求再进行开发，就算今天 Retool 的估值和财务情况已经很宽裕，团队规模也不到100人，这样的谨慎让我们相信 Retool 大概率能活过可能到来的大萧条。

从团队组成来看，Retool 内部最大的两个部门是 Engineering 和 Sales。其中 Head of Engineering Snir Kodesh 曾在 Lyft 做了7年的资深工程总监，而 Head of Sales Paul Goodman 曾在 Mapbox 做了7年的销售总监。值得指出的是，尽管 Retool 的 GTM 策略不需要太多的 Marketing，因为 PLG 策略只需要 Sales 去对接需要升级成付费策略的团队，但 Retool 还是请来了 Stripe 首位 Market 负责人 Krithika Muthukumar，她在工作了9年后于2022年中加入 Retool，侧面反映了其对公司未来的看好。

这不得不提到 Retool 的特殊融资策略，才能吸引来各种硅谷新势力中的资深员工。尽管 Retool 的估值已经高达 32 亿美元，但实际上已有投资人愿意为 Retool 健康的财务情况和高速增长的 ARR 支付更高的估值，但 David Hsu 考虑到后续新员工的财务回报，从而能够吸引更多的人才，尽量将估值控制在50亿以下，并每轮的融资额都不高，这将能让让员工的期权性价比更高。

05.

竞争：开源和无代码

低代码是一个极为拥挤的赛道，根据 Stride VC 的投资人 Pietro Invernizzi 在其一篇博客中的统计，当前有数百家低代码/无代码公司，他罗列了 12 个细分行业中 145 家比较重要的。其中我们可以看到其他团队要么专注于高效开发移动和网页端 APP，比如 Webflow 和 Outsystems；要么重视工具之间的工作流自动化，比如 Zapier 和 Workato；要么强调构建表单，定制运营和财务处理小程序，可视化分析工具等，比如 Airtable 或 Purchasely。

我们认为 Retool 讨巧地选取当时无人关注的内部工具赛道作为主要宣传方向是其成功的重要原因。2017年创办的 Retool 在当时的市场环境里有太多的前辈，比如 2001 年创办的 Outsystems，2012年的 Zapier 和 Airtable。想让用户选取一个年轻且没有明显创新的产品很难，更何况当时 Retool 当时的梦想 — 重构软件的重构软件的开发方式）在低代码行业里都显得那么普通。在 Hsu 耐心倾听无数个潜在客户的需求后，巧妙地将公司的宣传方向转为服务企业内部工具开发，提供和之前类似的功能，却精准捕捉一块足够大的肥肉 — 企业客户的长尾 SaaS 需求。将梦想放低，步子却走得更稳了。

在内部工具开发赛道里，Retool 竞对中呼声最高的便是被叫做“开源 Retool”的 Appsmith，“无代码 Retool” 的 Bubble 也有一定的关注度。

Appsmith - 主要竞争对手

Appsmith 是一款印度团队于2019年开发的开源版 Retool。当前在 Github 有着 22000 颗星，并于2022 年 8 月完成了 4100 万的融资，投资人中包括 Accel。

虽然 Appsmith 的产品功能几乎和 Retool 相同，但是在实现路径上存在一些区别：

· 从技术上：卡拉云（国内模仿 Retool 的公司）创始人蒋川在其博客中提到，Appsmith 在前端的 React 代码版本较旧，同时用来状态管理的 Redux Saga 是一个很小众的管理库，这都意味着用户将遇到大量的 Bug，而显然开源软件将不会有客服来处理，只能依靠社区内的互助。

· 从商业化上：Appsmith 主要通过提供安全登陆，版本控制和在线客服来鼓励用户付费。但从官网上看，当前没有和大公司的合作，更多的是初创企业。

整体上看， 我们认为 Appsmith 商业化成果将难以超过 Retool，但可能会抢占一定的初创企业市场。不过需要密切关注社区的建设，一个活跃的社区将使得 Retool 的客服失去竞争力。除了 Appsmith，Superblocks 和 Airplane 也是潜在竞争对手，这两家近期都有 3000 万美元左右的融资额，但目前没有太大威胁。

Bubble.io - 无代码竞争对手

Bubble.io 是一家于2012年创立的无代码开发平台，于2021年7月完成了融资额为1亿美元的 A 轮融资。其主要功能是允许非程序员用户开发工作中所需的轻量应用，这将跟 Retool 抢占一部分的轻量用户，比如 Bubble 的客户案例中有大量的自由职业者，帮助他们开发轻量个人财务工具等。

至少从内部工具赛道来看，低代码比无代码方案更适合。因为内部工具的特点是业务逻辑复杂，功能需求宽泛，所以低代码所能保持的高可定制化才能满足，而无代码方案则需要长时间和用户的沟通后才能打磨出完整的产品。

Zapier - 企业工作流竞争对手

Workflow 作为近期的新产品线，显示了Retool 想要进一步扩大企业预算份额的野心。Retool Workflow 和 Zapier 的最主要的区别在 Retool 有着跟数据库的整合，而 Zapier 则专注于对 SaaS API 的全覆盖。整体上来说，Retool 因为有数据库的整合将在企业市场里更有竞争力，但跟 Zapier 的先发优势和更完整的 SaaS 整合还有较远差距。

06.

壁垒和局限

壁垒

1. 黏性极高，放大先发优势

内部工具开发是一款黏性极高的产品，因为没有公司想再次从零搭建一套内部工具。不少客户表示当内部工具在客服团队铺开后，这些工具显著降低了团队协作的磨损，使得他们积极地扩充人员，因为 Retool 将扩容的成本也压得很低，如果想换一套内部工具，几十个面板将需要半年以上的时间再开发，这几个月内客服团队将无事可做，甚至可能需要再培训。所以通常来说，只要 Retool 没有重大安全问题或离谱的价格，几乎不会有用户愿意重新搭建。如果说 Airtable 通过沉淀客户数据来保证长期留存，那么 Retool 则沉淀了客户的业务逻辑。

由于 Retool 几乎是这个内部工具的低代码开发最早的玩家，积累了数十家重要客户资源，产品高粘性的特点将放大其先发优势。这些明星企业的合作案例将吸引更多有需求的用户优先采用 Retool 作为首要的解决方案，不仅有望继续吸引到类似 Plaid 的明星企业提供高速增长的订单，而且有望成为传统巨头的工具现代化进程中的主要提供商。

2. 产品功能完备

Retool 的产品已经针对内部工具的需求进行了完整的覆盖，竞品在产品本身上难以形成明显竞争优势。内部工具开发并没有产品技术上的优势，主要还是对客户的需求进行深掘后完成覆盖。由于 Retool 是赛道内最早的玩家，在成立初也以积极了解客户需求而闻名，所以 Retool 的产品已然做的比较完备了。就算竞品开发出了独特的前端功能，由于行业技术壁垒不明显的特点，Retool 也能快速补全。

3. 高度可定制化

尽管 Retool 是低代码产品，但用户能在产品内部几乎所有地方使用 Javascript，提高效率的同时也保证了自由度。

现代内部工具的搭建基本都是采用 Javascript 和以其延伸开发框架（如 React，jQuery等），所以 Retool 的开发文档中花费了大量篇幅介绍如何让用户在各个开发环节直接使用 Javascript 以及丰富的开发辅助包，确保最好的自由度。

局限

1. 技术壁垒不高

Retool 的团队中没有设置 CTO，可以看出这个行业几乎没有技术门槛，所以在公司早期市场上有很多模仿者的话，将很难和其他公司有差异化。但是当前 Retool 不仅有着市面上最全面的前端组件，还有在博客中积累了大量来自明星公司员工的 Reference，以及当前行业内毋庸置疑的龙头地位，这在尊重原创想法的美国 SaaS 环境中已然形成了无形的品牌和客户壁垒。

2. 数据库部分的性能和体验难以达到极致

尽管 Retool 支持大部分数据库产品，但是有客户反馈 Retool 对大规模的数据库没有做特殊的优化，导致增删查改时速度较慢。而由于产品将请求引擎（Query Engine）进行封装，并不允许用户自定义，从而难以到达极致性能。

除此之外，超大规模的数据库需要处理的请求是极其复杂的，这可能需要几百行 SQL 代码，Retool 的编写界面比较基础简陋，尤其是没有 debug 工具，导致用户体验难以达到极致。

07.

业绩和估值

业绩

根据 Scara 数据，他们在 2022 年 11 月时预估 Retool 的 2022 ARR 将能达到 8200 万美元，且过去两年的 CAGR 为183%。（其历史数据如下表）。从下图中看出，这样的收入规模增速远超 Zapier 和 Airtable 的早期表现。

根据 a16z 对 50M+ ARR 的 Saas 公司统计，假设 Retool 是一家略好于市场平均水平（处于 50-75 %）的公司，它的 YoY ARR Growth 大概能落在 58-90% 之间。考虑到宏观经济因素和 SaaS 增长可能的放缓，我们将预估的业绩整理成下表。我们认为 Retool 的收入规模极有可能落在 Bear 和 Base 之间。

· Bear：在 23-25 年维持 50% 的 CAGR ，在 26-27 年维持 25% 的 CAGR

· Base：在 23-25 年维持 75% 的 CAGR ，在 26-27 年维持 50% 的 CAGR

· Bull：在 23-25 年维持 100% 的 CAGR ，在 26-27 年维持 75% 的 CAGR

估值

我们近期在市场最低点附近（2022.10.30）统计了美股二级 SaaS 的估值水平，发现市场能接受的 PS 倍数中位数降低到 5x 左右，Top 5 SaaS 的中位数是11x，接近 2016 年的水平。考虑到市场极差时公司几乎不会 IPO，所以我们稍微乐观地使用刚从短熊复苏的 2019 年数据，以 12 家 SaaS IPO 时的各类指标中位数作为参考。（由于数据并不是特别全面，存在混用 Revenue、LTM Revenue、ARR 的情况，这将会对计算 Multiple 时造成一定的不准确，所以仅供参考。）

考虑到 Retool 的 Operating Margin 大概率比这个数据更好，很有可能每年都在持续赚钱，所以将能支撑更高的 Revenue Multiple，这里我们用 17x。这个倍数远低于 2021 年的 25x，所以并不能算是盲目乐观。

当前 Retool 的年收入为 8200 万美元，考虑到 2023 年大概率能达到 75% 的 YoY Revenue Growth，其 2023 年的年收入预计将能达到 0.82 * 1.75 = 1.435 亿美元左右。我们认为 1.4 * 10 = 14 亿美元以下是个不错的进入估值，再根据上面对收入的估算给一个 IPO 退出时的回报率，算到 2027 年的原因是公司通常在成立 10 年左右进行 IPO。

08.

结论

Retool 绝对是一家值得关注的公司。上轮融资估值为 32 亿美元，考虑到熊市背景，我们认为估值在 14 亿美元以下值得投资，将能在 IPO 时取得不错的回报。我们认为公司完全有能力长期可持续发展，具体原因如下：

为什么看好？

1. 市场规模可观，利润率较高

据推算，低代码内部工具开发在美国市场的 TAM 有望达到年 200 亿美元，足够诞生上百亿美元级别的公司。并且随着产品的完善、渗透率的提高和产品的全球销售能力增强，TAM 有望在几年内快速增长。因为产品的完善将进一步提升开发者效率，从而节省公司的薪资开支；Retool 估算自己的渗透率时表示现在不到 0.1%，还有较大增长空间; 内部工具开发在全球都有庞大需求，预计 TAM 远不止于此，将能滋养百亿级别的 SaaS 公司。

此外，根据 CEO Hsu 在播客中透露，Retool 不仅不需要大规模烧钱扩张，而且在公司早期就能持续盈利，形成可持续增长。内部工具开发并不需要在技术研发方面的高投入，反而需要时间深掘客户需求后打磨产品；结合创始人的谨慎扩张风格，没有为了扩张而盲目烧钱。所以 Retool 的各种成本并不高，甚至在公司早期就基本实现盈利，并有消息称能维持二三十年的 Burn Rate，财务情况优秀。

2. 产品、客户和品牌壁垒

经过多年的孜孜打磨，Retool 的产品已在 UI、后端和前端的功能覆盖上已然比较完备。由于开发工具技术壁垒不高的特点，Retool 未来也可以快速跟上潜在竞品的新功能。现在正在通过移动端、工作流等新业务来完善企业工具开发的产品线。从客户反馈中看出，Retool 将开发人员的效率提高 25-75%，效果显著。

Retool 的客户群已覆盖众多行业和巨头，它们的背书将增强 Retool 的地位。Retool 的客户分布在金融服务、电商平台，零售团队、媒体娱乐业甚至是传统制造业，其中不仅有科技新贵，也有传统巨头。说明内部工具的变革不仅发生在新经济驱动者上，也正在改革既有格局。

Retool 是内部工具低代码开发的先发者和定义者，已形成品牌壁垒。在我们的硅谷笔记中提到，硅谷尊重原创想法，作为这个赛道最早且最好的选手，当有公司需要改进内部工具开发时，他们将自然地先想到 Retool 作为首选。

3. 长期主义的团队和增长策略

Retool 创始人愿意主动降低估值来吸引硅谷最优秀的人才，已有多个科技新贵的部门主管加入 Retool。公司先后吸引到了 Lyft，Mapbox，Stripe 等明星公司的部门主管，因为 Retool 主动压低估值的策略，将让他们买到的期权盈亏比更高。

Retool 增长策略最大的特点是长期主义。首先是多角度和客户沟通后深掘用户需求，再结合 PLG 的定价策略和 SLG 的团队结构来广挖客户付费能力，最后再通过多轮融资来增强公司可靠感，确保能获得大客户的信任和订单。

有什么顾虑？

1.独特的融资策略可能压低投资人回报率和可投规模

Retool 的融资策略是不盲目追求高估值，这将不利于投资人的回报率和可投规模。Retool 融资时多次表示公司主动压低了估值和融资金额，因为公司业务早已实现盈利且并不缺钱，但这将意味着投资者的可投资规模和回报率的不尽人意，将需要投资者更多的耐心。

2. 产品部分环节的体验和性能难以达到极致

Retool 为了低代码的效果妥协了一部分的体验和性能的优化。比如对于数据库的请求引擎（Query Engine），不仅不允许自定义引擎优化器，并且没有 Bebug 工具，让产品在面对极为复杂的请求（数百行代码）时，体验和性能很难达到极致。

3. 开源的竞对已有不错的产品和社区

Retool 最主要的竞争对手是开源的 Appsmith，目前已有不错的产品和社区。尽管在产品和商业化上和 Retool 还有一定的差距，但是随着社区的增长和对产品的优化，预计将能有力地抢夺 Retool 在初创公司的市场份额。

特别感谢

特别感谢拾象 Fellow，SaaS 从业者 Xiangzhou Xia 对本研究的帮助。

Reference

https://onretool.com/reports/state-of-internal-tools

-2022/

https://retool.com/blog/cost-benefit-analysis-of-

internal-tools/

https://www.glassdoor.com/Salaries/software-

engineer-salary-SRCH_KO0,17.html

https://onretool.com/reports/state-of-internal-

tools-2022/

https://www.naics.com/business-lists/counts-by-

company-size/

https://statisticalatlas.com/United-States

/Occupations

https://galorath.com/software-maintenance-costs/

https://courses.cs.vt.edu/csonline/SE/Lessons

/LifeCycle/Lesson.html#refs

https://www.internal.io/blog/internal-tools-cost-

benefit-analysis

https://sacra.com/c/retool/

https://www.indiehackers.com/podcast/181-david

-hsu-of-retool

https://zhuanlan.zhihu.com/p/477330274

https://sacra.com/c/retool/

https://sacra.com/p/retool-internal-app-builder/

https://retool.com/blog/series-c/