AI Toolbox:32美元成本两周上线,两年达成五位数MRR
Leveraging a marketplace and existing user bases to hit a 5-figure MRR in two years
AI Toolbox · AI对话管理扩展 · 2周上线 · 五位数MRR
- ⚡首版仅花32美元耗时两周上线,全程零广告投入
- 🎯靠Chrome商店自然流量+用户反馈飞轮实现自增长
- 🚀本地跨平台搜索是大厂商永远不会做的差异化护城河
- 💡把客服直接转化为增长渠道,月运维成本仅45美元利润率极高
2人仅花32美元成本两周上线AI对话管理扩展,主打多平台AI对话本地搜索管理,靠用户反馈迭代获客,月运维成本仅45美元,不到两年实现五位数MRR。

解决自身痛点
Scratching his own itch
我是阿迪·莱维姆,拥有7年以上产品开发经验的全栈开发者,和穆罕默德·埃尔-伊萨维共同创立了Infi Developments。我们两人合计拥有12年SaaS开发经验,分工明确:我负责产品开发、前端架构和AI集成,穆罕默德负责后端架构、算法和LLM系统。两人团队没有冗余流程,用户反馈的问题当天就能修复。2024年年中我们日常使用ChatGPT做编码、研究、写作和头脑风暴,几个月后积累了数百条对话,却找不到历史内容,没有文件夹、没有自有消息搜索、没有导出批量管理功能,只能翻侧边栏找历史对话。所以我们开发了想要的产品:AI Toolbox,一款浏览器扩展,为ChatGPT添加嵌套文件夹、全文跨消息搜索、书签、提示词库和批量导出功能,最初仅支持ChatGPT,现在已经兼容Gemini、Claude和Grok。我最自豪的是没人主动要求的功能:跨四个平台同时搜索,索引运行在用户本地设备,永远不会上传到我们的服务器。没有任何AI大厂会推出这个功能,因为这意味着要索引竞争对手的产品,这就是我里程碑们公司的核心定位。2024年9月我们在Chrome应用商店上线产品,不到两年时间覆盖150多个国家3.5万活跃用户,评分4.5/5,获得谷歌精选标识,MRR达到五位数。
I'm Adi Leviim, a full-stack developer with 7+ years of building products. I cofounded Infi Developments with Mohammad El-Esawi. Together, we have about 12 years of shipping SaaS, and we split the work cleanly: I lead product development, frontend architecture, and AI integrations, while Mohammad handles backend architecture, algorithms, and LLM systems. Two people, no committee. This allows us to ship a fix the same day a user reports it. In mid-2024, we both used ChatGPT daily for coding, research, writing, and brainstorming. After a few months, we'd each had hundreds of conversations, with no way to find anything within them. No folders. No search within your own messages. No way to export or bulk-manage. We both scrolled sidebars, hunting for a chat we knew was there. So, we built what we wanted: AI Toolbox, a browser extension that adds nested folders, full-text search across every message, bookmarks, a prompt library, and bulk export. It started as ChatGPT-only, but now it works with Gemini, Claude, and Grok. I'm proudest of the feature nobody asked for: search that spans all four platforms at once. It runs on an index that lives on your own device and never touches our servers. No AI company will ever ship this feature, because building it means indexing their competitors. That's our company's entire thesis in one line. We launched on the Chrome Web Store in September 2024. Less than two years later, we have 35,000+ active users across 150+ countries, a 4.5/5 rating, a Featured badge from Google, and a 5-figure MRR.
Who is it for?
- ✓全栈独立开发者
- ✓有浏览器扩展开发经验的创业者
- ✓AI效率工具赛道从业者
Not for
- ✗无前端开发经验的新手
- ✗追求快速变现的投机者
- ✗依赖大模型公开API的工具开发者
验证需求后辞职
Validating and quitting his job
两个开发者的痛点不等于市场需求,所以我们在开发前先去Reddit和OpenAI官方论坛找用户自发的吐槽,这些都是远高于主动调研的强需求信号,没人会为了需求验证方法小不便专门发论坛帖子。我们发现用户反复抱怨找不到旧对话、没有文件夹、不能搜索自己写的内容、无法导出数据,这些抱怨直接成了我们的首版功能列表,完全不需要猜需求。我和穆罕默德之前在同一家初创公司是同事,确认了彼此的协作能力之后,我们没有用业余时间兼职做,直接辞职全力投入项目。
Two developers being irritated by something is not a market, so we looked for other people's complaints before building anything. Specifically, we went where people complain unprompted: Reddit and OpenAI's official community forum. That's a completely different signal from asking people what they want. Nobody writes a forum post about a mild inconvenience. We found the same handful of frustrations repeating in other people's words: I can't find my old chats, there are no folders, I can't search what I actually wrote, I can't get my data out. Those complaints became our first feature list almost verbatim. We weren't guessing what to build; we were transcribing. That made the decision easy, and it wasn't a small one. Mohammad and I were full-time colleagues at the same startup. We met there, and that's why we already knew we could build together. Once we had this idea, we didn't try to squeeze it into nights and weekends. We quit our jobs and went all in on AI Toolbox.
联合创始人建议
首版仅花32美元耗时两周
Spending $32 and two weeks on v1.0
初始开发成本就是32美元:27美元MVP成本的后端虚拟机,5美元的Chrome应用商店开发者年费,没有代理、外包、融资和广告投入,只有我们两个人的时间。第一版只做了一个功能:搜索聊天历史,没有文件夹、导出等后续功能。上线两周后我们根据用户需求推出批量操作功能,现在产品的35个功能几乎全是后续用户提出来的,现在用户最常用的批量导出和//提示词快捷功能首版完全没有。
The initial build cost us $32 and took two weeks. That isn't a joke or a rounded figure: $27 for a virtual machine to run the backend, and $5 for the Chrome Web Store developer fee. That was the entire capital cost of the company. No agency, no contractors, no investment, no ad spend. Just the two of us and our own time. The first version did exactly one thing: it searched your chat history. That's all. No folders, no export, none of what the product is today. We went through those forum complaints, picked the sharpest one, and built only that. Two weeks after launch, we shipped bulk actions, allowing you to select a pile of chats and delete or archive them, as people kept asking for this next. We now have over 35 features, and almost every one after the first arrived similarly: a customer requested it. The two features people lean on most today — bulk export and the "//" prompt shortcut — weren't in that first build at all.
MVP策略
架构决策
Architecture decisions
扩展用纯TypeScript开发,没有引入React、Vue等UI框架:内容脚本是注入到第三方DOM中的访客,每多1KB代码都会增加用户页面加载负担,引入框架运行时很容易和宿主应用冲突。我们用原生TypeScript直接操作DOM,用webpack打包,esbuild-loader提速,Terser压缩体积,需要和宿主样式隔离的UI用Shadow DOM渲染。Chrome的Manifest V3规则极大影响了我们的架构:服务后台随时可能被杀死,所有数据不能常驻内存,必须存在数据库里,所有操作要支持幂等重试;MV3不支持运行时动态加载JS分片,所以我们只能打包成单个bundle,严格控制体积。后端架构非常精简:用TypeScript写的Node+Express,MongoDB做数据库,Redis做限流,全部运行在单台Ubuntu服务器上,用Nginx做反向代理,PM2保活,没有K8s、微服务等冗余组件,数据库不暴露在公网,所有存储数据加密,仅存储文件夹名、标签、保存的提示词这类组织数据,PDF导出功能用服务端无头Chrome运行,渲染完立刻删除数据,解决多语言排版兼容问题。最核心的决策是搜索完全在本地索引运行,所有对话缓存在用户浏览器的IndexedDB里,搜索请求不会到我们服务器,既保护隐私,还实现了秒级搜索,零额外API成本,后续跨平台搜索功能也完全基于这个设计实现。核心技术决策
The extension uses TypeScript with no UI framework (no React, Vue, or others). This is a deliberate choice, not laziness: a content script is a guest in someone else's DOM. Every kilobyte we ship adds to the user's page load, and pulling a framework's runtime into a page we don't own is a great way to fight with the host app and lose. We use plain TypeScript and direct DOM work, bundled with webpack, esbuild-loader for speed, and Terser to keep it small. UI that must be bulletproof against the host page renders into shadow DOM, ensuring their styles and ours cannot conflict. Chrome's Manifest V3 shaped our architecture more than any framework decision. Two constraints stand out. First, the service worker can be killed at any moment, so nothing can live in memory and expect to persist. Everything is stateless or database-backed, and every operation must be safely repeatable. Second, and this one bites people: an MV3 content script cannot load JS chunks at runtime. Code splitting silently fails. It's not a build error or a catchable exception; it's simply a feature that doesn't work in production. So we ship one eager bundle and treat bundle size as a real budget rather than something the bundler solves for us. The backend is deliberately boring, and I mean that as a compliment. We use Node and Express in TypeScript, MongoDB, and Redis for rate limiting, all running on a single Ubuntu droplet behind Nginx with PM2 keeping the process alive. That's the whole thing. No Kubernetes, no microservices, no managed anything. The database lives on the same box, which sounds quaint until you realize it means the database is not exposed to the internet at all. We encrypt everything we store at rest. What we store is only the organizing layer: folder names, tags, saved prompts. The one piece of real machinery is PDF export, which runs through headless Chrome on the server — the conversation is rendered in the moment, and nothing is retained afterward. Getting typography and full Unicode right client-side is a losing battle when your users write in Hebrew, Arabic, Japanese, and Chinese. The decision I'd most strongly defend from those early weeks was to run search on a local index. Every conversation is cached in IndexedDB in your own browser, and search runs there, not on our servers. We chose it for privacy, as we were uncomfortable holding other people's conversation history, and it proved to be the best product decision. Search is instant, a bulk export of fifty chats costs zero extra API calls, and two years later, it's the only reason we could build cross-platform search at all.
技术选型思路
逐步迭代商业模式
Shifting the business model gradually
上线前三个月产品完全免费,不是免费增值模式也不是试用,我们只有一个功能也没有知名度,需要先攒到足够的用户和社区反馈,第一年几乎所有功能都来自这段时间的用户建议。之后我们推出免费增值模式:免费版有合理的功能限制,付费版分月付和终身方案,用Lemon Squeezy做支付,免费版本身就足够好用,大多数付费用户都是免费用户用到功能上限之后自然转化的,不是被营销转化的。当我们支持多平台之后,把支付迁移到Polar,新增跨全平台访问的All Access套餐和团队席位套餐,每新增一个支持的大模型平台,All Access套餐的价值就自动提升,而我们的开发成本几乎不会增加,因为所有功能都是共享模块,新增平台只需要写一层薄适配器。早期我们定价偏低,这是故意的:早期功能少就定低价,后续功能越来越多之后逐步涨价,现在我们月基础设施成本只有40美元,加上支付渠道手续费和少量OpenAI API调用成本,月总支出才45美元,完全不需要融资,没有烧钱压力,可以做长期十年维度的决策,不需要为了 runway 焦虑。
For the first three months, the extension was completely free. Not freemium, not a trial. Free. We had one feature and no reputation, and we couldn't get feedback without users. That period gave us the two things we needed: daily users and a community to tell us what to build next. Almost everything we shipped in year one came from that period. Then, we launched freemium: a free tier with limits and Premium as monthly or lifetime plans, running on Lemon Squeezy. The free tier isn't a crippled demo. It's genuinely useful on its own, which matters because most paying users started as free users who hit a wall doing real work, rather than being sold to. When we went cross-platform, two things changed. We moved billing to Polar and added plans that only make sense once you're on four sites: All Access, which covers ChatGPT, Claude, Gemini, and Grok, and a seat-based tier for teams. That's where expansion lives. A user who buys for ChatGPT and then starts using Claude has an obvious next step; it's the same product they already trust. Every new platform we add makes All Access worth more without changing our build costs, since features are shared modules and each platform is a thin adapter. We were also badly underpriced at the start, and I'd defend that. Early on, we had a handful of features, so we priced it like a product with a handful of features. As the product grew, we raised prices because the product you buy today is not what we sold in 2024. People don't believe our expenses. Our infrastructure bill is a $40 VM. It was $27 at launch, and we upgraded it to something stronger; that upgrade represents our entire infrastructure spend history. The only other running costs are Polar's cut of each sale and about $5 a month of OpenAI API usage for the one feature that needs it: we summarize a conversation for context injection at the moment you ask for it, and we don't store it. We deliberately run it on the cheapest nano-tier model. Two people, one droplet, and $45 a month, at 5-figure MRR. We never raised money, so we never had to grow into a burn rate. This means we can make decisions on a ten-year horizon instead of a runway.
变现策略
用户评论与创作者回复
已过滤 spam、低价值附和与重复内容 · 原始 50 条 · 展示 9 条 · 创作者回复 8 条
It's been stated over and over, but one of the highlights of this process is the recycling of human feedback into the product as an enhancement engine.
这个案例最值得关注的点是把用户反馈直接转化为产品迭代的引擎,大多数团队都会忽略用户抱怨的价值。
笔记:验证了把用户抱怨直接转化为迭代需求的可行性,大幅降低产品决策成本。
Reframing complaints as suggestions is half of it. The other half, for us, was accepting that frequency is not the only signal worth acting on.
把抱怨重新定义为改进建议只是一半,另一半是我们意识到需求出现的频次不是唯一值得参考的信号。
笔记:补充说明哪怕只有一个用户精准描述的问题,也值得优先修复。
Curious: when you moved from free → freemium, what was the free-tier “wall” that converted people most often?
很好奇你们从全免费切换到免费增值模式时,哪个免费版限制点的付费转化率最高?
笔记:聚焦付费转化的核心卡点,对同类工具定价有极高参考价值。
The one that converted best wasn't a feature cap, it was the search result limit. Free gets 5 results.
转化率最高的不是功能限制,而是搜索结果数量限制,免费版仅展示5条结果。
笔记:在用户主动搜索急需内容的场景下设置付费卡点,转化率远高于功能使用限制。
Two weeks from problem to launch is wild discipline — most of us spend months polishing before shipping. Curious how you identified which marketplaces actually had the right user overlap vs. ones that just looked promising on paper?
两周从痛点到上线的执行力太强了,大部分人都要花几个月打磨产品才敢发布,想知道你们怎么判断哪些分发平台有精准用户?
笔记:聚焦冷启动阶段的渠道筛选方法,适合所有独立开发者参考。
The test I use is whether the marketplace's own search bar already contains the problem. If people are typing "chatgpt folders" into a store search, the intent exists.
我的判断标准是平台自带的搜索框里是否已经有人在搜你要解决的问题,比如有人搜“chatgpt 文件夹”,就说明需求真实存在。
笔记:平台内搜索量比平台总用户量更能证明精准用户的存在。
The "two developers being irritated by something is not a market" line hit hard. I built something recently based purely on my own annoyance, skipped checking if anyone else was actually complaining about it in their own words first.
“两个开发者的痛点不等于市场需求”这句话点醒了我,我之前完全基于自己的不爽做了个产品,完全没去查有没有其他人也在吐槽同样的问题。
笔记:点出很多独立开发者容易犯的自嗨式创业错误,给出了明确的修正方向。
One tip for that Reddit search: look for complaints written by people who tried to solve it themselves (scripts, spreadsheets, workarounds) - effort is a much stronger signal than upvotes.
给你一个Reddit搜索的小技巧:找那些已经自己尝试用脚本、表格等 workaround 解决问题的用户,他们投入的行动成本比帖子点赞数强得多。
笔记:给出了比点赞数更精准的强需求判断标准。
The "the ground moves" part is the one I'd want a whole separate post on. Undocumented endpoints and DOM selectors is your entire business risk in one sentence.
“底层平台随时会变”这部分我特别想看到完整的单独文章,基于未公开接口和DOM选择器做产品的风险完全浓缩在这句话里。
笔记:聚焦浏览器扩展类产品的核心风险点,是同类开发者最关心的问题。
Honest answer: the first signal used to be support emails, and it stung enough that we changed the architecture instead of just adding monitoring. Every UI attachment point now has multiple fallback anchors.
说实话最开始我们发现平台变动的信号就是用户投诉邮件,这痛得我们直接重构了架构而不是只加监控,现在每个UI挂载点都有多套 fallback 锚点。
笔记:给出了平台变动风险的实际工程解决方案,非常有实操性。
The line worth framing is "we never raised money, so we never had to grow into a burn rate."
最值得抄录的一句话是“我们从来没融过资,所以从来不需要为了匹配烧钱速度而被迫增长”。
笔记:点出无融资创业的最大优势,完全掌握自己的产品节奏。
That freedom cost us some speed early on, but we'd make the same trade again.
这份自由早期确实让我们损失了一些增长速度,但我们永远会做同样的选择。
笔记:验证了低运维成本无融资模式的长期价值。
Looking back, was there any complaint that looked common on Reddit/forums but turned out to be a poor business opportunity once you started building?
回顾过往,有没有哪个在Reddit上看起来呼声很高的抱怨,做完之后发现根本不是好的商业机会?
笔记:帮大家区分“大声吐槽”和“愿意付费”的需求差异,避坑效果拉满。
And yes, there's a clear example: bulk delete. If you search Reddit for ChatGPT complaints, "let me delete all my chats" is everywhere. Constant, angry, upvoted. We built it early expecting it to convert, and it basically doesn't. The reason took us a while to see: it's a one-time pain.
有个非常典型的例子就是批量删除功能,Reddit上到处都是用户喊着要删所有聊天,我们做完之后发现几乎没人为它付费,因为这只是一次性的痛点,用户清理完一次就再也不需要了。
笔记:明确给出了无效需求的判断标准:一次性痛点哪怕呼声再高也不值得做付费功能。
Every "fill the gap in a big platform" business is racing the platform's own roadmap. What separates the ones who survive from the ones who get absorbed: use the platform-gap wedge to acquire users cheap, then build value the platform won't replicate.
所有填补大平台功能空白的创业项目都在和平台自己的 roadmap 赛跑,能活下来的都靠平台空白点低成本获客之后,快速搭建平台永远不会复制的差异化价值。
笔记:点出了平台依赖类产品的长期生存策略,避免被大平台抄死。
Really liked the point about turning existing user feedback into a growth channel. It’s easy to focus only on getting new users, but improving the experience for people who already use the product can have a much bigger long-term impact.
把用户反馈转化为增长渠道这个观点太赞了,大家都盯着拉新,却忘了服务好现有用户的长期价值大得多。
笔记:点出了零成本增长飞轮的核心逻辑,适合所有资源有限的独立开发者。
Every fix we ship for someone who already uses the product eventually shows up in a review or a recommendation, which is where the new users come from.
我们给老用户修复的每一个问题,最终都会变成好评或者推荐,新用户自然就来了。
笔记:闭环解释了服务老用户和拉新之间的正向循环关系。
Localization Notes
- 国内可适配文心一言、通义千问、豆包、Kimi等主流大模型平台,快速复刻跨平台AI对话管理核心功能
- 分发渠道替换为Edge应用商店、国内主流浏览器扩展分发平台,无需从零搭建获客入口
- 支付体系接入微信/支付宝,替换海外支付工具Lemon Squeezy/Polar,符合国内用户使用习惯
- 本地索引不存储用户对话数据的设计完全符合国内数据安全合规要求,隐私风险极低
- 冷启动可从国内AI工具用户聚集的知乎、V2EX、小红书社区挖掘用户自发吐槽的痛点,快速验证需求
- 同类赛道目前已有少量竞品,但跨多平台全量覆盖的成熟产品不多,仍有较大市场空间