Bannerbear：把「自动生成图片」做成百万美金 API 生意
Bannerbear 解决的是一个特别无聊的问题:批量生成图片。
电商要给几千个商品生成带价格的促销图、媒体网站要给每篇文章自动配 Open Graph 预览图、SaaS 要给用户生成带数据的分享卡片——这些活以前要么靠设计师一张张做,要么靠程序员写一堆 Canvas 代码。Bannerbear 把它做成了一个 API:你定义好模板,传数据进来,它自动吐出成品图。
就这么个听起来不性感的东西,创始人 Jon Yongfook 一个人做到了接近 100 万美元的年经常性收入(据其在 Indie Hackers 公开的里程碑数据)。这篇拆解它是怎么做到的。
从「12 个月 12 个产品」里跑出来的
Jon Yongfook 是常驻新加坡的独立开发者。Bannerbear 不是他的第一个产品——它是他给自己定的「12 startups in 12 months」(12 个月做 12 个产品)挑战的产物。
在做出 Bannerbear 之前,他连续上线了好几个产品,大多没成。这个挑战的逻辑很简单:与其在一个没验证的点子上死磕一年,不如快速做一批,看哪个有市场反应。Bannerbear 就是那个跑出来的。
值得注意的是,这个 idea 来自他自己的真实痛点。他在做多个项目时,每个都要反复制作社交媒体配图,几百张变体改来改去,烦透了。他不是凭空想了个点子,而是把自己每天在受的罪做成了产品。
关键转折:从「维生素」到「止痛药」
Bannerbear 早期增长并不快。Jon 后来复盘时提到一个关键转变——产品定位从「维生素」转向了「止痛药」。
这是个值得每个独立开发者记住的区分:
- 维生素型产品: 有了挺好,没有也行。用户觉得「不错」但不会急着付钱
- 止痛药型产品: 解决一个具体的、正在疼的问题。用户有明确的痛,愿意立刻掏钱
早期 Bannerbear 把自己描述成一个「方便的图片生成工具」(维生素),增长乏力。后来重新聚焦到具体的、有真实付费意愿的场景——比如「自动化你的营销图片生产流程」「给开发者的图片生成 API」(止痛药),瞄准那些每天被这个问题困扰、且愿意为解决它付费的人群,增长才起来。
同一个产品,换一种定位和目标人群,结果完全不同。
商业模式:API + 订阅
Bannerbear 走的是 API 优先 + 订阅制:
- 核心是 API,开发者把它集成进自己的应用,按用量分档订阅
- 也提供无代码的集成(如 Zapier、Make),让非技术用户也能用
- 定位 B2B——客户是公司和开发者,不是个人消费者
这个模式的好处:
- 客户黏性高: 一旦集成进客户的工作流,迁移成本高,不容易流失
- 收入稳定: 订阅制带来可预测的经常性收入
- 天然规模化: 客户业务增长,用量增长,你的收入跟着涨
API 生意的典型特征是「前期获客难,后期黏性强」。开发者集成一个 API 要花时间,但一旦集成好、跑通了,几乎不会主动换掉。
Build in Public:边做边晒
Jon 长期践行 build in public——公开分享收入、增长、踩的坑。他提到自己长期保持大约「一半时间写代码、一半时间做营销」的投入比例。
这个 50/50 的分配对独立开发者很有启发。技术出身的人容易陷入「我把产品做到完美,用户自然会来」的幻觉,把绝大部分时间花在写代码上。Jon 的做法说明:对独立产品来说,营销和产品至少同等重要。 公开建设本身也是营销——它持续产生内容、积累关注、建立信任。
对中国开发者的启示
Bannerbear 这个案例,有几点特别值得借鉴:
1. 无聊的问题往往是好生意。 自动生成图片听起来一点不酷,但正因为它无聊、重复、没人愿意手动做,才有人愿意付钱让它自动化。别只盯着性感的点子,盯着那些让人烦躁的重复劳动。
2. API 是适合独立开发者的好模式。 一个人维护、B2B 黏性高、可规模化、不需要做花哨的前端。如果你是技术型独立开发者,把能力封装成 API 卖给其他开发者,是一条被反复验证的路。
3. 定位比功能更重要。 同样的产品,「维生素」定位增长乏力,「止痛药」定位才跑起来。做产品前先想清楚:谁正在为这个问题真实地疼着?(这一点和 选品与方向验证 里讲的完全一致。)
4. 快速试错胜过押注单一。 Bannerbear 是「12 个月 12 产品」里跑出来的。先用低成本试多个方向,比在一个没验证的方向上死磕一年更明智。
数据来源:Jon Yongfook 在 Indie Hackers 的公开里程碑及多家创业媒体报道,具体数字以其本人公开披露为准。
相关阅读:选品与方向验证 · Pieter Levels:一人公司的极致