运营中

Stripe工程师周末做的邮件订阅SaaS。连续5年月增5%,做到月收入7.5万美元

Stripe工程师Justin Duke于2016年12月作为周末副业创立的邮件订阅SaaS Buttondown。过去5年几乎每月保持约5%增长,月收入达7.5万美元(约1125万日元)。第7年即2023年才转为全职。

Stripe工程师周末做的邮件订阅SaaS。连续5年月增5%,做到月收入7.5万美元

由于金额以美元计价,正文中附有按1美元150日元换算的大致金额。

用7年做到月收入1125万日元

Buttondown是Justin Duke于2016年12月作为副业开始撰写的邮件订阅发送SaaS。当时他的本职是Stripe工程师。创业动机既不是市场调研也不是商业计划,而是一个非常个人化的不满——“受够了用Tinyletter”。

这份副业在7年后做到了月收入7.5万美元(约1125万日元)。但这个案例并没有一夜之间轨迹突变的瞬间,有的只是”几乎每月5%“这个朴实数字连续保持了5年的记录。这里还包括了哪些事情”没有发生”,值得一并追踪。

数字全貌

项目数字
月收入7.5万美元(约1125万日元)
增长率过去5年,几乎每月约5%(环比)
团队规模创始人1人(唯一全职)+ 兼职外部合作者2人
客户数“数万人”(本人表述)
资金无外部融资。盈利——“We’re profitable and growing!”
起步2016年12月,在Stripe任职期间的夜晚及周末副业
转全职2023年(即全职投入的第一年)

值得说明的是,发布该案例的Starter Story文章标题为”$15K/Month”,但同一页面的简介栏和正文都显示月收入为7.5万美元。本文采用正文中的数字。

停滞与加速的时间线

时期事件
2016年12月开始开发。对Tinyletter的不满是出发点
上线时同时登上Hacker News和Product Hunt首页。独立访客约3万 → 注册用户约500 → 付费客户约10人
早期同时采用按量计费和按功能计费的定价设计,引发大量咨询
将定价统一为常见的SaaS制式
2019年增长”非常不理想”。“好的月份”=拿到1个新客户的月份
2023年月收入达7.5万美元“好的月份”=MRR增加约1000美元。首次全职,也能支付两名外部合作者的报酬

同一句”好的月份”,内涵从”新增1个客户”变成了”MRR增加1000美元”。这就是这4年间实质性变化的全部。

卖的是什么

Buttondown是一款用Markdown书写、可直接发送、外观克制的邮件订阅发送工具。技术选型为Django、Heroku、Vue、Sass。他刻意避开了流行框架,明确采纳了”选择无聊的技术(Choose Boring Technology)""少构建(Build Less)“的理念。

Duke有一句话:“这个世界上有大量渐进式改进的空间(There’s a lot of room in the world for incremental improvements)“。他的判断是:在一个已经庞大的既有市场中,只需增加一个更快、更简单的选项就足以立足。事实上他所列举的差异化因素并非功能的丰富程度,而是”速度""对客户诉求的响应速度""有主见的极简设计”。

没有戏剧性转折,起作用的是复利与客户自带的曝光面

这个案例没有可以称之为转折点的瞬间。上线时的热度并未转化为营收,直到2019年新客户获取速度仍是每月1人。真正起作用的,是从未中断”月增5%“这件事本身。

月增5%持续60个月约等于增长18.7倍(1.05的60次方)。以7.5万美元反推,5年前应在4000美元/月左右,但这只是记者一方的简单计算,并非本人披露的数字。而且这与2019年”好的月份=新增1个客户”的说法并不能直接吻合——一个月收入4000美元规模的业务想要月增5%,需要相当数量的新客户支撑。“5%增长持续5年”的起点,很可能略晚于2019年,且很可能包含了老客户单价上涨的部分。这是需要留意的模糊之处。可以确定的是,他在很长时间里以副业形式低空飞行,直到达到7.5万美元才转为全职这一先后顺序。

那么,为什么5%增长没有中断?背后有三个结构性原因。

1. 客户的产出本身就是流通渠道。 Duke说:“几乎每一封邮件和公开的网页存档页脚,都有『powered by Buttondown』的行动召唤。也就是说,获客和留存的大部分工作是客户替我们完成的。“这不只是一个病毒式传播的技巧。邮件订阅SaaS天然具有一种特质:客户的产出会公开呈现在不特定的多数人面前。客户越多,曝光面就越大,而且这些曝光面只要客户不流失就会持续存在。广告费花完即消失,但页脚会像库存一样不断累积。这种获客成本随客户数量增长而下降的结构,是这类产品本身内置的。

2. 把定价的复杂性当作摩擦的感应器来处理。 早期同时采用按量计费和按功能计费。得到的教训很清楚:“如果客户因为『不知道自己最终要付多少钱』而发邮件来问,那就是一个坏信号”。他把关于定价的咨询数量,重新解读为衡量定价表设计缺陷的指标,并将其统一为常见的SaaS制式。病毒式结构对摩擦很敏感,如果通过页脚而来的人在定价表前止步,增长就不会被放大。

3. 选择无聊的技术,把时间投入到响应速度上。 “敏捷是一种超能力(Agility is a superpower)“这句话,反映的正是他一人体制下7年间没有把时间花在追逐技术潮流上,而是花在了对客户诉求的即时响应上。

渠道运营也颇具特色。他在Twitter、博客、邮件这三个渠道重复发布相同内容,毫不犹豫。理由是:“大多数用户都会忽略除了一个渠道之外的所有渠道”。与其担心内容重复而减少发布量,不如接受重复,这是他做出的判断。

没有奏效的事情

  • 上线时的热度: HN和PH同时登上首页,吸引了约3万独立访客,付费客户却只有约10人。付费转化率仅0.03%。“关注”几乎没有转化为营收。
  • 持续到第3年的停滞: 2019年时”好的月份=新增1人”。如果当时就放弃,就不会有7.5万美元的今天。
  • 早期的定价设计: 双重计费模式,他自己承认是一次失败。

可复制与不可复制的部分

可以复制的是页脚行动召唤带来的自我放大效应、定价的简化,以及对无聊技术的选择。但页脚行动召唤起作用的前提是,产品属于客户产出会变成公开物的那一类。面向企业内部使用的工具无法复制同样的结构。

难以复制的是前提条件本身:身为Stripe工程师的技术能力,以及作为副业坚持7年的生活基础。转全职是在月收入达到7.5万美元之后才做出的决定,他并没有先辞职再干。Duke本人的建议也集中在三点:“做一个即使自己是唯一用户也会满意的产品""区分可以挽回和无法挽回的决定(名字和API契约属于后者)""要有耐心,这不是一场短跑,而是一场马拉松中的马拉松”。

相关推荐

出处

本文是对上述公开信息的摘要与分析。详情请务必确认一手资料。

本文允许在新闻媒体、博客或生成式AI回答中自由引用与转载:只需注明出处「Small Start(small-start.com)」并附上本页链接,无需事先联系。 转载与引用政策 →

相似案例

如果本页对您有帮助,欢迎分享
分享到X