将内部工具转型为七位数业务
公司 : Gleap
创始人 : Lukas Böhler
收入 : >$83K/月
Lukas Böhler 为他的代理机构构建了一个内部工具,并通过客户进行了验证。然后,他推出了、重新品牌化并成功将 Gleap(链接)发展成为一个年营收 7 位数的企业。
以下是 Lukas 分享他的成功经验。 👇
内容
从零打造年营收 7 位数的自力更生业务
我是 Lukas,Gleap 的联合创始人兼 CEO。我的背景是软件工程——在创立 Gleap 之前,我和他人共同创立并运营 BoehlerBrothers,这是一家位于奥地利多恩比恩的软件代理机构,多年来我们为客户开发和构建应用程序和产品。
Gleap 是从我们在代理机构每天面临的痛点中诞生的:客户在冗长且模糊的邮件中报告 Bug,这让开发人员无法采取行动。我们构建了一个内部工具来解决这一问题,而验证过程几乎是偶然的——当客户看到它时,他们不断询问是否也可以使用它。这表明这不仅仅是我们的问题,于是我们在 2020 年将其作为 BugBattle 推出。2021 年,我们将其重新品牌化为 Gleap,并将其从代理机构中独立出来,成立了一家独立的公司,我的联合创始人 Isabella Salzmann(COO)和 Tobias Duelli(CTO)也加入其中。
Gleap 已经从一个 Bug 报告工具演变为一个全功能的、AI 驱动的客户支持和反馈平台——我们的愿景是“自我修复的软件”。其核心是 Kai,我们的 AI 代理套件:
Kai 处理跨渠道的第一层级(Tier-1)支持对话。
Kai Resolve 利用技术上下文调查问题。
Kai Code 将 Bug 报告转化为可直接合并的拉取请求。
Kai PM 对反馈进行聚类,并与用户形成闭环。
Kai 周围汇集了现代软件团队与用户交流所需的一切:实时聊天、应用内 Bug 报告、知识库、调查、产品导览以及公开路线图——用一个平台取代了碎片化的工具堆栈,如 Intercom、Zendesk、Instabug 和 Canny。
其进步不言而喻:今天,有超过 4,500 个软件团队(从独立创始人到微软、Squarespace、联合国儿童基金会和 Papa John's 等公司)正在使用 Gleap,我们的 Widget 每月覆盖约 2.5 亿终端用户。
我们处于自力更生状态且已实现盈利,约 75% 的客户位于美国。对于许多客户来说,Kai 现在在人类介入阅读之前,就已自主解决了大多数第一层级(Tier-1)支持对话。
我们跨越了 7 位数 ARR(年经常性收入)的门槛并实现了盈利,自然增长率为每月 4-8%。
构建第一个版本
我们将初始产品作为代理机构内部的一个副业项目进行构建。我们没有为此拨出预算或融资——我们在客户项目之间挤出时间来做这件事。
这就是从代理机构起步的优势:我们已经拥有工程人才、基础设施和现金流,因此代理机构的收入和我们自己的无偿工时基本上资助了第一个版本。当我们将 Gleap 独立出来成为一家公司时,奥地利初创生态系统提供的助学金帮助填补了其中的缺口。
第一个版本是有意设计得很精简的:这是一个你可以放入应用的 SDK,它让用户可以通过摇晃手势或点击按钮来报告 Bug,同时自动捕获截图、控制台日志、网络请求和设备数据。因为我们是自己的第一个客户,反馈循环既残酷又迅速——我们的开发人员在真实的客户项目中每天使用它,因此几周内我们就知道什么有效、什么无效。我们的代理机构客户成为了第一批测试人员,他们的反应告诉我们,我们拥有值得追求的东西。
我们站在了前人的肩膀上:开源框架用于我们的 SDK,标准的云基础设施允许一个小团队比十年前快得多地发布原生 SDK,适用于 iOS、Android 和 Web。
总体而言,从第一个内部版本到作为 BugBattle 的公开发布,大约花了一年的时间——少数几个人构建了它,我们自己的代理机构为其提供了资金,并且在第一个陌生人付费之前,我们就在真实的项目上验证了它。
标准的技术栈
Gleap 核心是一个 TypeScript/Node.js 团队。后端使用 Node.js 配合 MongoDB 作为主要数据库,随着数据量的增长,我们添加了 ClickHouse 用于分析和事件数据——Widget 每月覆盖约 2.5 亿终端用户,因此事件和会话的写入量超出了仅靠 MongoDB 存储的合理范围。我们在其周围运行一个相当标准的堆栈:Paddle 用于计费、Postmark 用于交易邮件,以及 New Relic 用于监控和可观测性。
我们技术栈中最具特色的部分是 SDK 层。由于 Gleap 活跃在我们客户的应用程序内部,我们维护了七个原生 SDK——JavaScript、iOS、Android、React Native、Flutter、Capacitor、C# 和 Cordova——这意味着我们必须跨所有平台构建和测试每个功能。这是我们最大的持续工程挑战之一:在七个代码库之间保持与一个小团队的功能对等,而每个平台在截图、控制台捕获和网络日志方面都有自己的特性。
当我们转向 AI 优先时,技术栈发生了最剧烈的变化。构建 Kai,我们的 AI 代理套件,意味着在现有平台之上叠加了一个全新的栈:LLM 编排、基于客户知识库和技术上下文的 RAG(检索增强生成)管道,以及 Langfuse 用于 LLM 的可观测性和评估——因为当 AI 自主回答大多数第一层级(Tier-1)支持对话时,我们需要像监控正常运行时间一样来测量和追踪答案质量。最难的一课是,开发一个 AI 功能,20% 是在编写提示词,80% 是在评估、护栏和上下文工程上。

两部分的商业模式
Gleap 是一个经典的 B2B SaaS 订阅业务,带有基于使用量的 AI 层。我们的方案从单人开发者每月 999+ 不等(包含 SOC 2、SSO、BYOK),按年或按月计费,提供 14 天免费试用且无需信用卡。
除了订阅之外,Kai(我们的 AI 代理套件)的 AI 使用量按代币消耗和模型选择计费。这种两部分模式是经过深思熟虑的:订阅涵盖了平台,而 AI 使用量随着客户从产品中获得的价值增长而增长。
我们从第一天起就开始收费。来自代理机构的背景让我们从未有过烧 VC(风投)钱供免费用户使用的奢侈(或诱惑)——Gleap 必须能够养活自己,因此验证付费意愿实际上也是在验证这个想法。
我们的定价自那时以来发生了显著变化:我们最初推出了廉价的人均计划(约 $19–119/月),最终转向了基于价值的平台层级,在更高层级的计划上提供无限席位。这种转变非常重要——人均定价惩罚了我们想要鼓励的特定行为(整个团队都使用 Gleap),而平台定价加上 AI 使用量则使我们的收入与客户价值保持一致,而不是被习惯所束缚。
收入增长来自三个方向。
计划升级: 团队从 Starter 或 Team 开始,随着更多地采用该平台,逐步升级到 Pro 和 Enterprise——Kai Resolve、Kai Code 和 Kai PM 是 Pro 及以上级别的功能,随着客户实现更多自动化,这为他们提供了自然升级的理由。
AI 使用量: 随着 Kai 处理客户支持量中日益增长的部分,基于代币的收入也随之增长,而无需重新协商。
整合: 因为 Gleap 取代了一系列点状解决方案——Intercom、Zendesk、Instabug、Canny——扩张通常意味着客户将预算从三个工具转移到一个工具上。
转向 AI 优先导致了我们最大的收入拐点。推出 Kai 改变了交易规模和买家的对话:我们从“一个不错的反馈 Widget”变成了“这能将你的支持工作量减少一半”,这是每家 SaaS 公司都理解的一个预算项目。
给有抱负的企业家的建议:尽早收费,即使这感觉不舒服——一个支付 $19 的客户教给你的东西比一千个免费用户教你的要多。并且比你认为合理的频率更频繁地重新评估你的定价。大多数创始人在发布时设定一个价格,然后每两年才回顾一次;几乎每次我们根据价值而不是习惯重新定价时,收入都会增长,且流失率没有上升。
SEO 和产品驱动增长(PLG)
如我提到的,我们的第一批用户来自我们现有的网络。作为一家代理机构,我们将产品部署在我们自己的客户项目上,这些客户——加上我们网络中的其他代理机构——成为了首批付费客户。这给了大多数发布所缺乏的东西:真实的生产环境使用和来自第一天的推荐。
当我们作为 BugBattle 公开发布时,我们做了典型的初创公司发布流程——Product Hunt、beta 列表、开发者社区——这带来了第一批陌生人,更重要的是,教会了我们美国软件团队才是我们的真正市场,而不是本地企业。今天,大约 75% 的客户位于美国,在奥地利运营。
内容和 SEO 对我们来说增长最为显著。我们持续发布买家积极搜索的主题内容——AI 客户支持、支持自动化、与 Intercom 和 Zendesk 的工具比较——多年来,这建立了一个有机引擎,每天带来试用注册,而无需付费支出。与此同时,像 G2 这样的评价平台也在默默而稳定地发挥作用:当支持线索筛选工具时,我们会出现在比较组合中,并带有社会认同。
产品本身是我们最不寻常的渠道。Gleap Widget 活跃在我们客户的应用程序内部,每月覆盖约 2.5 亿终端用户。相当一部分新注册用户来自那些在别人产品的内部遇到 Gleap 的人,无论是作为终端用户还是作为客户团队成员。每一次部署都是面向恰好正确受众的一个小型广告牌:那些构建软件的人。我们通过自助模式来强化这一点——14 天免费试用,无需信用卡,1 小时内设置完成——所以好奇心在不需要销售电话的情况下就能转化,再加上一个初创计划(第一年 50% 折扣),这让我们能够进入早期公司并伴随其成长。
AI 的转变也改变了我们的市场进入策略。随着 Kai 的推出,我们停止销售功能,开始销售结果——“大多数第一层级(Tier-1)支持在人类阅读之前就已经被处理”——而这一信息打开了 Bug 报告工具无法打开的大门,包括微软、Squarespace 和 Papa John's 这样的大客户,而他们的 Logo 也随之为自己代言。
我的增长建议:选择那个能产生复利效应的渠道,并要有耐心。付费广告在你停止付费的那一刻就停止了;内容、评论和产品驱动分布在你睡觉时依然在发挥作用。不要低估你现有的分销渠道——我们的代理机构网络给了我们第一批客户,而我们自己的 Widget 成为了我们表现最好的渠道。大多数创始人都有某种不公平的分销优势;秘诀在于识别它。
给独立黑客的建议
我的建议是什么?
熟悉现代编码代理和工具。
构建 MVP(最小可行性产品)
尽早收费
做客户支持并倾听用户的意见!
永不放弃。每天不断推进——即使是微小的改进也会积累!
未来展望?
我们的目标是成为支持“自修复软件开发”的平台,允许每个人将其软件置于自动驾驶模式,专注于对其业务重要的事情,从而不再在客户支持、Bug 修复等方面浪费资源。
你可以在 LinkedIn 上关注我。并且查看 Gleap!
Indie Hackers 通讯:订阅以获取每周 3 次发送给你的独立黑客最新故事、趋势和洞察。
订阅

M. Sumama·Aug 12
What stands out most here isn’t the 7-figure ARR—it’s the path to getting there. Building an internal tool for a problem you personally experience, then seeing customers naturally ask to use it, is one of the strongest forms of product validation.
I also really like the evolution from a narrow bug-reporting tool into a broader customer support platform. The pricing shift from per-seat to value-based pricing is another underrated lesson; aligning pricing with the outcome customers actually care about can completely change the economics of a SaaS.
The SEO + product-led distribution piece is especially interesting too. Instead of relying heavily on paid acquisition, Gleap turned content, customer deployments, and organic product exposure into compounding distribution.
A great reminder that sometimes the best SaaS opportunity is hiding inside a problem you’ve already solved for yourself.
AnshikaR·Aug 12
The agency-to-SaaS transition is the part I find most interesting. Having real clients validate the problem before launching seems like a huge advantage. The bigger challenge then becomes turning that initial validation into a repeatable growth channel.
MORPHOICES.·Aug 12
The part of this story that is interesting is that the pivot appears to have been in identifying the value in a market that already exists on the inside, and not in attempting to create a new market from scratch.
Those pivots are always fascinating to me because sometimes internal tools can come with a solution to a very specific problem, that really works. The question is whether the problem is present in the original team or not, without making many assumptions.
It also appears that the mindset around positioning, onboarding and who it truly serves is different when transitioning to real business.
The moral of the story is that sometimes the greatest product idea comes from an idea that you came up with because you needed it yourself.