EmailEngine:资深开源开发者靠15年积累做到月入1.3万美元
From open-source donations to $13k MRR with EmailEngine
EmailEngine · 邮件开发者工具 · 5年以上 · $13K/月 MRR
- ⚡依托15年Nodemailer开源积累,零营销投入做到1.3万美元月收入
- 🎯反常识选择Redis作为主数据库,大幅降低用户部署门槛
- 🚀全自助无销售模式,完全避免托管运维和大客户对接压力
- 💡拒绝指数级爆发,年增速20%实现低焦虑可持续慢增长
资深开源邮件开发者依托15年行业积累,打造自托管邮件API工具,零营销成本获客,实现低压力慢增长稳定盈利。

从开源捐赠到1.3万美元MRR
From open source to SaaS(ish)
我是一名邮件软件开发者和开源维护者,最广为人知的作品是Nodemailer,全球数十万开发者和企业都在使用它。虽然开源项目能带来曝光和影响力,但没法覆盖日常开支,我收到的定期捐赠每月只有几百美元。大约5年前,我决定把自己在邮件基础设施领域的经验转化为商业项目,最初计划开发多款产品,最终核心聚焦在EmailEngine上——这是一款自托管应用,开发者可以通过简单的HTTP REST API访问邮箱账户,无需直接处理IMAP、SMTP或是微软Graph、Gmail这类厂商专属AP产品定位I。我们当前的MRR收入里程碑为1.3万美元,年增速约20%,增长曲线平缓稳定没有指数级爆发。
I’m an email software developer and open-source maintainer. I’m best known for my open-source work — most notably Nodemailer, which is used by hundreds of thousands of developers and companies worldwide. While open source brings a lot of visibility and impact, it doesn’t really pay the bills. I do receive regular donations, but they’re in the low hundreds per month. About five years ago, I decided to turn my experience in email infrastructure into a business and started a company that builds and sells email software. The original plan was to build multiple products, but in practice, one clearly stood out. Since then, I’ve been focused almost exclusively on EmailEngine— a self-hosted application that lets developers access email accounts via a simple HTTP REST API instead of dealing directly with IMAP, SMTP, or vendor-specific APIs like Microsoft Graph or Gmail. We're currently at $13k MRR, growing at roughly 20% per year. Revenue growth has been slow but steady, so the revenue chart has no sudden bumps or exponential curves — just a mostly linear line from zero to its current position.
Who is it for?
- ✓有长期开源项目积累的开发者
- ✓深耕垂直小众技术领域的独立开发者
- ✓追求低压力慢增长的创业者
Not for
- ✗期望快速爆发式增长的创业者
- ✗缺乏垂直领域技术积累的新手
- ✗依赖销售转化的ToB产品创业者
burnout之后冷静创业
Burning out and starting up calmly
我之前在一家风投支持的初创公司做了4年CTO,长期高压工作导致 burnout,之后我决定做没有压力的项目,不提供托管服务、不接大客户、不设销售团队,所有客户都是自助服务的小型技术团队,不需要额外的支持服务,原本打算靠积蓄休息的项目最终变成了可持续的生意。反内卷心态
I was the CTO of a small VC-funded startup for four years. I took my laptop to the toilet and put it under my pillow while sleeping, just in case something happened and required a fast reaction. After four years, I was burnt out. I wanted a break. As a long-time developer, taking a break still meant working — just without the pressure. That mindset shaped many of my decisions later. It’s also why I don’t provide managed hosting or take on large customers. If someone contacts me asking for a demo or wants to negotiate with “my sales team,” I kindly point them to some of my competitors instead. All my customers are self-serve — usually competent, small technical teams that don’t require hand holding and therefore don’t burden me with constant support requests. What was originally meant to be a short break until I ran out of cash reserves turned out to be a viable business. I’ve been doing it ever since.
核心创业心态
非常规技术栈选择
An unusual tech stack
EmailEngine基于Node.js开发,用Redis作为主数据库,这个选择并不常见,Redis通常被用作缓存层而非主数据库,但它的有序集合数据结构完美适配技术栈选择IMAP索引需求,同时也降低了用户部署的复杂度,虽然我需要花很多时间实现传统数据库自带的功能 workaround,但整体利大于弊。
EmailEngine is built on Node.js and uses Redis as its database. The homepage is hosted on umso.com, and the documentation is a Docusaurus project hosted on GitHub Pages. I also use Claude Code a lot these days. Using Redis as the main database is not a very common choice — Redis is usually seen as a caching layer rather than an actual database. In my case, Redis was the option that had the best compatibility with IMAP indexing, specifically because of its Sorted Set data structure. Without going too deep into the details, that was the deciding factor. I also didn’t want to ask users to set up multiple databases for different purposes, so I decided to use Redis for everything. It’s a choice I’ve sometimes regretted. Redis is missing a lot of features you’d normally expect from a database, like proper querying, and that has meant spending time implementing workarounds I wouldn’t have needed with a more traditional DB. That said, keeping things simple has helped overall. It’s much easier for users to spin up their first trial instance for testing, and once someone is already testing the product, they’re much more likely to start paying.
技术选型思路
找到正确的商业化路径
Finding the model
项目最初只是业余开源项目,前两年我都是在下班时间开发,最初想靠它提升Nodemailer的捐赠收入,效果不好之后尝试AGPL+商业MIT双授权模式,也几乎没有客户买单,直到我完全转为商业订阅模式之后才开始获得付费用户。产品采用14天免费试用机制,之后需要付费订阅才能继续使用,订阅按年自动续费,用Stripe管理,只有一个统一的订阅档位,没有增售和分层,所有用户获得完全相同的产品商业化转折。
EmailEngine started out as yet another open-source side project, so for the first two years, I worked on it in my free time while still at my previous job. Initially, I didn’t intend it to become an actual business. The idea was to use it to increase the donations I was getting for supporting my open-source software development. That didn’t really work, so I tried a dual-licensing approach. The open-source version was licensed under AGPL, and for “serious businesses” I offered an MIT-licensed version for a small yearly fee. There were almost no takers for that either. This phase took about a year and a half. Eventually, I decided to go fully commercial, and almost immediately started gaining customers — mostly previous users of the free project, but also companies that wanted continued updates and upgrades. So now, it is self-hosted software that requires a paid subscription to operate. Without a subscription, it runs in a 14-day free trial mode, after which it stops working. Subscriptions are yearly and self-renewing, and I use Stripe for subscription management. There is only a single subscription plan. There are no upsells or tiers — everyone gets exactly the same product, whether they’re a solo developer or a large bank.
变现模式设计
靠开源项目实现零成本增长
Growth via open source projects
我没有刻意推动增长,只是持续迭代产品,最早的10个订阅用户都是项目还叫IMAP API、在GitHub获得1000星标时期的老用户。我完全采用工程化营销,从自己所有的开源邮件相关项目导流到EmailEngine,营销预算一直是0,另外通过发布竞品对比类SEO文章也获得了不少精准客户。零成本营销
I didn’t push for growth. I just kept developing the product, saw that there was steady growth, and assumed that eventually it would get there — and it did. The first ~10 subscribers were all users of EmailEngine back when it was still an open-source project. At the time, it had a different name - IMAP API. IMAP API was fairly popular, with around 1,000 stars on GitHub. Otherwise, I’ve used a single growth “strategy” from the beginning. I’d call it engineering-led marketing. I’ve released a number of popular open-source and free products, and linked from those to EmailEngine. Since all of these projects are email-related, there’s a natural overlap. For example, a Nodemailer user might eventually need features that Nodemailer doesn’t provide, but EmailEngine does — such as Microsoft Graph API–based sending using OAuth2. In those cases, they may end up checking out EmailEngine, and in rare cases, they end up paying for it. I’ve never done paid ads — my marketing budget has always been $0. The only other approach worth mentioning has been SEO. In particular, the “EmailEngine vs. some major alternative” type of articles. Users of those alternative providers who aren’t happy with their service go looking for options, find EmailEngine, and some of them turn into customers.
增长策略组合
找到你独有的竞争优势
Look for your edge
我过去15年维护Nodemailer积累的行业经验和开发者信任是最大的竞争优势,标注「Nodemailer作者出品」大幅提升了产品可信度。我给独立开发者的建议是找到你自己独有的优势,很多时候你自己都没意识到长期积累的技能是别人无法复制的壁垒。接下来我会继续迭代EmailEngine,借助AI提升开发效率,探索更轻量化的纯邮件发送类新产品,我对当前的收入水平非核心建议常满意,没有刻意追求更高的增长速度。
My background in building open-source email projects has been a big advantage. Over the years—Nodemailer is 15 years old by now—I’ve gained fairly rare experience in a topic that is both complex and boring for most people. Along the way, I’ve also built an audience of developers who already use my projects. Labeling EmailEngine as “made by the creator of Nodemailer” definitely makes it more trustworthy. Nodemailer has been around “forever” and quietly does its thing, so people tend to assume EmailEngine will probably do the same. Here's my advice: Look for an edge you might have — one that either you haven't noticed yet or you don't think of as an edge. For example, I never considered my open-source work to be a growth driver for a business. It only turned into one after I had already started. I plan to keep building EmailEngine, and maybe return to my original idea of building multiple related projects. I’ve had many ideas over the years, but haven’t had the time — EmailEngine has been large enough to require my full attention. Now, with AI, software development has become much faster, so I might revisit some of those old ideas. As far as revenue, I have no plans to increase it beyond its current trajectory. As a solo business with essentially no cost base, and living in Eastern Europe, I’m quite happy with the current state.
关键里程碑
2011年 · 启动开源项目Nodemailer,积累数十万全球开发者用户
2021年 · 业余启动EmailEngine前身IMAP API,获得1000 GitHub星标
2022年中 · 放弃双授权模式转为全商业订阅,获得首批付费用户
2026年1月 · 达到13000美元MRR,年增速稳定20%
用户评论与创作者回复
已过滤 spam、低价值附和与重复内容 · 原始 50 条 · 展示 8 条 · 创作者回复 0 条
Classic indiehacker pivot, turning 15 years of open-source 'boring' expertise into a $13k MRR solo business by building what devs actually need, not what VCs want.
非常经典的独立开发者转型案例,把15年开源领域的“枯燥”经验转化为月入1.3万美元的单人业务,做开发者真正需要的产品,而不是风投想要的产品。
笔记:点出了独立开发者避开VC逻辑,深耕小众领域的核心优势
Are you finding that your user base from the donation days converted well, or did you have to go hunt for an entirely new customer segment that values the product side more?
好奇早期开源捐赠阶段的老用户转化情况如何,还是说你需要完全开发一批更愿意为产品付费的新客群?
笔记:问到了开源商业化最核心的用户转化问题,是很多开发者最关心的点
The self-hosted positioning is also a smarter market bet than it might appear. The companies that care most about IMAP abstraction are often enterprises or regulated industries that can't route sensitive email data through a third-party SaaS.
自托管的产品定位比看起来聪明得多,对IMAP抽象需求最强的往往是金融、医疗等合规行业,他们根本不能把敏感邮件数据传到第三方SaaS服务商。
笔记:点出了自托管产品的天然高价值客群,避开了普通SaaS的价格战
Curious about the single-tier pricing decision. At $13k MRR with one plan, you must have a pretty wide range of customer sizes. Do you ever get pressure to add enterprise tiers, or does the 'no demos, no sales team' filter those out naturally?
很好奇单一订阅档位的决策,月入1.3万的情况下用户规模差异很大,你有没有遇到过要求增加企业版档位的压力,还是说无演示模式自然过滤掉了这类需求?
笔记:针对单一定价策略的深度提问,戳中了很多独立开发者的定价痛点
I especially liked the part about deliberately choosing not to chase growth or large customers — that’s something many founders intellectually agree with, but struggle to actually do in practice.
我特别喜欢主动选择不追高增长、不做大客户的部分,很多创业者理智上认同这个逻辑,但实际执行的时候根本做不到。
笔记:点出了慢增长模式最难的部分是创始人的自我克制,而不是技术或者流量问题
What I find most interesting here is how unambitious this is — in the best possible way. There’s no growth hack, no monetization gymnastics, just a deep, unsexy problem solved by someone who’s spent 15 years living inside it.
这个案例最棒的地方就是它“没有野心”,完全没有花里胡哨的增长黑客或者变现花招,只是一个人花15年深耕一个没人愿意碰的枯燥问题。
笔记:总结出了小众独立业务的核心竞争力,就是长期深耕的深度,而不是短期的技巧
What I'm stealing from this: stop rebuilding. Ship one version. Fix it for 5 years. The depth comes from iterating on the same codebase, not burning it down every 6 months.
我从这个案例里学到的最有用的一点:别反复重构项目,发布一个版本,持续打磨5年,深度来自于对同一个代码库的迭代,而不是每半年就推翻重来。
笔记:给很多喜欢反复重构产品的开发者非常实用的行动建议
Lots of users doesn’t mean lots of buyers. Buyers show up when the tool is tied to a painful, time-sensitive job.
用户多不等于付费用户多,只有当工具和用户痛苦的、有时间压力的强需求绑定的时候,才会有人愿意付费。
笔记:点破了很多开源项目看似流量大但赚不到钱的核心原因
国内落地参考
- 国内邮件协议适配需求真实存在,大量企业需要简化IMAP/SMTP接入流程,替代复杂的原生开发
- 可直接复用Node.js+Redis技术栈,替换Stripe为微信/支付宝订阅支付体系,部署成本极低
- 依托自身现有开源项目导流获客,完全零付费营销成本,不需要投入推广预算
- 主打金融、医疗等合规要求高的行业,自托管属性刚好满足数据不出境的监管需求,差异化优势明显
- 避开直接做邮件发送SaaS的红海赛道,切入小众邮件基础设施蓝海,竞争压力极小
- 可参考单一订阅档位设计,无分层无增售,完全消除定价和销售沟通成本,单人即可运营