Bannerbear 的故事颠覆了传统创业路径：一个设计师转型独立开发者，在连败6个项目后，用API工具打造出年收60-90万美金的可持续生意。本文将拆解其从产品定位到商业模式的六步实战路径，揭秘如何在不融资不追风口的情况下，用技术解决重复设计痛点的精妙逻辑。
今年春节，我几乎没怎么出门。
大部分时间在看一些海外独立开发者的创业故事。
看着看着，发现有一类公司反复出现：不融资、不追风口，却稳定赚钱很多年。
Bannerbear 就是其中让我印象很深的一个。
今天跟大家分享一下Bannerbear的故事和背后的业务逻辑。
很多人觉得，做技术产品要么去大厂领资源，要么拉一支十几人的工程团队。
有一个新加坡出身的设计师，叫 Jon Yongfook，曾任 Aviva 保险公司亚洲区数字产品与设计负责人，后来离职开始连续做独立产品。
2018 年开始他给自己定下“12 个月做 12 个产品”的挑战，前 6 个全部失败，烧掉了大部分积蓄，但第 7 个产品 Bannerbear 在 3 年左右爬到约 5 万美金 MRR，2024 年维持在约 5–7.5 万美金 MRR 区间，年收入在 60–90 万美金之间，并在 2022 年之后扩展为约 7 人远程小团队，始终没有拿过一轮融资。
这不是一个“独角兽融资故事”，也不是靠一次爆款收割的短期项目，而是一个关于“设计师用 API 工具做长期、自举型小而美生意”的案例。
他做的事情可以压缩成四步：先在失败产品中发现一个高频、可复用的技术痛点；把原来面向非技术用户的工具转成面向开发者的图片 / 视频生成 API；用订阅制加按用量计费模式，把少量高质量 B 端客户留在自己这边；用持续的 Build in Public 和“50% 编码、50% 营销”的节奏慢慢滚大到几十万美金年收入。
一个挑战里的第 7 个产品，配合同一套节奏和方法，被他打磨成了一个年收入 60–90 万美金、团队规模可控的 API 生意。
他做的产品是 Bannerbear。
核心功能包括：提供图片生成 API，用户设计一次模板，就能批量生成成百上千张带有动态文案的图片；提供视频生成 API，支持自动生成短视频用于产品演示或社交媒体；通过 Zapier、Make、Airtable 等工具集成，让不写代码的用户也可以在自己的自动化流程里调用这些能力。
典型用户包括：给 SaaS 产品或市场活动自动生成证书、海报、卡片的开发者；需要为大量商品批量生成促销 banner 的电商团队；需要每天为多账号、多平台生成视觉素材的市场团队；用 No‑code 工具搭建自动化工作流的个人创业者和运营人员。
收费模式以订阅制为主，从每月 49 美金的入门套餐起步，按照 credits 用量分档，企业客户可以选择更高档或定制方案，从而把“每月调用量”和“持续订阅”绑定在一起。
那他是怎么从一个失败了六个项目的独立开发者，走到一个年收入 60–90 万美金的 API 产品的，这背后有一条清晰可拆解的路径。
如果你想在中国做一个面向开发者或自动化场景的 API 生意，我通过六个步骤给你提供了一套从定位、定价到节奏和渠道的参考骨架。希望对你有帮助。
详细拆解：
2019 年左右，Jon 在做 Previewmojo，这个产品可以扫描网站并自动生成社交媒体分享图（OG image），主要卖点是帮非技术用户减少一部分设计工作。
在实际运营中，他遇到三个反复出现的问题：客户不断提出高度定制化模板需求，一个人做不过来；主要用户是不懂技术的站长和运营，而他更习惯与开发者对话；产品用例过窄，基本只覆盖分享图，增长空间有限。
这让他意识到，真正有强烈支付意愿的可能不是“偶尔需要一两张图”的终端用户，而是那些需要长期批量生成图片或视频的开发者、团队和项目方，他们更在意 API 稳定性、可集成性和自动化能力。
于是他做了一个关键转向：把 Previewmojo 背后的生成引擎抽象出来，做成 REST API，不再为每个客户做具体模板，只提供“根据 JSON 数据和模板自动生成图片 / 视频”的底层能力，由客户在各自场景里调用。
用户画像因此被重新定义为三类主力：需要在产品里嵌入证书、卡片、报告等动态图片的 SaaS 开发者；需要为上百上千个 SKU 批量生成促销 banner 的电商团队；需要按规则高频生成视觉素材的市场和 No‑code 用户，他们往往愿意为稳定 API 支付每月几十到几百美金的订阅费。
验证方式很直接：2019 年 9 月，他把 Bannerbear 以新项目形式重新发到 Product Hunt，当天就有开发者注册试用，首月拿到了第一批付费用户，证明面向开发者和自动化场景的定位要比原来的“站长工具”更有拉力。
Bannerbear 提供的核心价值可以概括为一句话：用 API 把“重复设计”变成“批量生成”。
其一是图片生成 API，用户设计一次模板后，可以通过传入不同的 JSON 数据，批量生成带有不同文字、头像或图标的图片，常见用法包括社交媒体配图、博客封面、电商促销图、证书和 OG 图等，这部分按 credits 计费，入门档每月 49 美金起，包含 1000 个 credits。
其二是视频生成 API，允许开发者或团队自动生成短视频，用于产品功能演示、社交媒体推广等，按照视频时长和复杂度消耗 credits，对希望自动化视频生产的营销团队有实际价值。
其三是 No‑code 集成，Bannerbear 通过 Zapier、Make.com、Airtable 等工具连接各种非技术场景，让不写代码的运营或个人创业者也可以在表格、表单和自动化工作流里触发生成操作，从而扩大使用人群，同时通过这些生态获得导流。
对典型用户来说，最直接的收益是节省人力时间，例如一个电商团队为 500 个产品做一轮促销，如果手工在设计软件里制作图片，可能需要设计师连续工作一周，而通过预先设计好的模板加 Bannerbear API，整个任务可以压缩到几十分钟内完成，这样每月几十到几百美金的订阅就变成可接受的固定投入。
因此，Bannerbear 并不是在卖“更好看的图片编辑器”，而是在卖“自动化的视觉生产能力”，匹配的是对规模化、重复性视觉内容生产有刚需的团队和项目方，而不是一次性用完就走的轻度用户。
Jon 的第一个显性优势是“设计＋编程”的复合背景，他曾在 Aviva 担任亚洲区数字产品与设计负责人，长期参与产品体验和视觉设计，同时自学 Ruby on Rails 并能独立开发完整的 Web 应用和 API 服务，这让他既能设计出开发者愿意用的界面和文档，又能在技术上承担后端实现和架构决策。
第二个优势是持续的 Build in Public，他在 Twitter 上长期以 @yongfook 身份分享创业过程，早期采用 Open Startup 模式公开 MRR 曲线，定期写 Newsletter 总结功能更新、收入节点和踩坑体会，长期积累出了大约六万粉丝，其中不少是潜在用户、合作伙伴或二次传播节点，即使后来因为各种原因下线了公开收入仪表板，这种透明文化依然留在他的内容风格里。
第三个优势是他给自己设定的“50/50 节奏”，也就是一周专注写代码，一周专注营销和内容，在博客、访谈和 Bannerbear 官方文档中，他多次强调技术创始人如果把百分之百时间都放在编码上，会忽视市场教育和获客，而这一套一周编码、一周营销的节奏，让产品在功能和市场认知上同时向前推进。
与很多只擅长工程或只擅长内容的创始人不同，他把这三点结合在一起：用设计和工程做出稳定的 API 服务，用 Build in Public 积累信任和早期用户，用 50/50 节奏持续把产品推到更多潜在客户面前，从而在无需融资的前提下，支撑 Bannerbear 走到几十万美金年收入的体量。
Bannerbear 的主产品是图片 / 视频生成 API，采用订阅制加 credits 计费的组合方式，把“调用频率”和“收入”绑定起来。
收费模式方面，官方公开的档位包括：Starter 档每月 49 美金，提供约 1000 个 credits；Growth 档每月 99 美金，对应更高的调用额度；Business 档每月 249 美金，提供更大规模的配额和额外功能；企业用户则可以协商定制化方案，覆盖更高的调用量和支持等级。
这种设计的关键点有三点：一是 credits 与实际调用次数或资源消耗挂钩，使收入跟随客户业务规模自然放大；二是入门价格不压得太低，避免吸引大量不稳定的小用户，把支持资源集中在愿意长期付费的团队和企业；三是企业用户有更高的 ARPU，可以让少量客户贡献可观收入，从而在总体用户数不需要特别庞大的情况下撑起 5–7.5 万美金 MRR 的体量。
在定价策略上，Jon 曾经犯过“过低定价”的错误，早期有 9 美金每月的低价方案，但首个付费客户很快就取消订阅，这促使他重新研究同类 API 产品的价格区间，并把起步价格提高到 49 美金每月，这样只需要数百个付费用户就可以达到数万美金级别的 MRR，而且用户本身更加重视服务质量和稳定性。
简单概括，Bannerbear 的商业模式就是：提供稳定易集成的 API 服务，以中高价格档位锁定有刚需的 B 端和高频使用用户，用订阅制和 credits 机制把客户需求和收入长期绑定，同时保持团队规模精简，把绝大部分现金流留在公司内部而不是用来“买增长”。
在 2020–2021 年的一人公司阶段，Bannerbear 的成本结构极其简单，主要是云服务和工具订阅，综合估算每月约 500–1000 美金，包括服务器和存储费用大约 300–500 美金，加上一些支付、邮件服务等工具的订阅费用约 200–300 美金，人力成本方面则是创始人自己全职投入，没有额外员工工资支出。
在这个阶段，假设收入在 1–4 万美金 MRR 区间波动，对应的毛利率可以轻松超过 90%，属于典型的高利润数字产品；这也是很多人误以为 Bannerbear 长期是“一个人、成本几百美金、利润率接近 99%”的原因，不过这种描述只对早期阶段有效。
从 2022 年起，Jon 开始有意识地组建小团队，根据他的博客和相关报道，当时 Bannerbear 已经有大约 7 名全职成员，分布在不同地区远程协作，这意味着总成本结构发生了明显变化，服务器和基础设施费用增加到了每月大约 2000–3000 美金，加上多人的薪酬之后，整体利润率自然低于早期的一人阶段，但在 5–7.5 万美金 MRR 的基础上，仍然有相对充足的余地支撑持续开发和运营。
获客成本方面，他依靠 Build in Public、SEO、博客内容和产品在各类开发者社区的传播，而不是大规模投放广告，因此在相当长的时间里，营销费用主要体现为时间成本和少量工具开支，而不是现金流出，这也是自举模式下控制成本、保持现金流安全的重要一环。
综上，Bannerbear 能在没有外部融资的情况下稳定运转，关键是早期通过极简成本结构快速跑到较高的 MRR，再在收入基础上逐步引入团队和更完善的基础设施，而不是一开始就背负沉重的固定成本。
从时间线上看，2020 年 1 月 Bannerbear 正式从 Previewmojo 的实验中独立出来时收入为零，当年内逐步获得首批用户，年底时 MRR 约为一万美金级别，主要来自早期采用者和通过 Product Hunt 等渠道接触到的开发者客户。
随着 2020–2021 年新功能的上线、SEO 内容的发酵以及 Build in Public 带来的口碑，2022 年 10 月 Jon 在博客中公开的收入数据是约 4.8 万美金 MRR，对应大约六百名付费用户，按平均每位用户几十至一百多美金的订阅额推算，与公开的定价档位相互印证。
进入 2023–2024 年后，增长明显放缓，根据多方来源汇总的数据，2024 年 2 月的 MRR 大约为 5.3 万美金，同年 10 月的一次估算高点接近 8.2 万美金 MRR，对应约 99 万美金年化收入，但综合 Jon 的更新频率和第三方文章判断，全年大致在 5–7.5 万美金 MRR 区间波动，比较合理的区间估计是年收入约 60–90 万美金，而非此前网络流传的 40 万美金 MRR。
在这种体量下，即便按团队和基础设施综合成本每月数万美金估算，Bannerbear 依然可以维持正向现金流和较高的净利润率，同时为未来的产品拓展和团队调整留出空间，从而成为一个对创始人和员工都相对稳定的小而美 SaaS 生意，而不是需要为估值和融资节奏反复调整方向的高速增长公司。
这里的关键不是“数字有多夸张”，而是“一个面向开发者的 API 产品，在合适的定价和成本控制下，可以在几百付费用户的规模上形成可靠现金流”，这是很多独立开发者和小团队可以参考的现实天花板。
在 Bannerbear 刚起步时，Jon 出于谨慎和拉新考虑，将首个付费方案定在每月 9 美金，这个价格在当时看起来更像面向个人或小项目的“轻量工具”，但带来的结果是吸引了不少尝鲜用户，却很难积累真正有长期预算和自动化需求的团队，甚至第一个付费客户在短时间内就取消了订阅。
反思之后，他系统研究了其他 API 产品和 B2B SaaS 的价格区间，很快把起步价格调整为每月 49 美金，通过提高门槛筛选更认真、更有预算的客户，并据此推算出“只需要 300–400 名付费用户就可以支撑 5 万美金 MRR”的业务目标，这一调整直接改变了后续收入结构和客户质量。
作为提供图片 / 视频生成的 API 服务，Bannerbear 一旦出现性能问题或被攻击，客户产品中的调用就会受到影响，某次遭遇 DDoS 攻击导致服务短暂中断，对方下游应用也受到连锁反应，这让 Jon 认识到在提升功能之外，基础设施安全和防护同样关键。
后来他将部分流量前置到 Cloudflare 等边缘网络上，加强防护和限流策略，对存储和计算资源做了更细致的分级和监控，以牺牲一点早期“极致低成本”为代价换取更稳的 SLA，这种调整在引入更多付费团队后显得必要。
在 Bannerbear 之前，他完成了“12 个月 12 个产品”挑战中的前六个，诸如 Play My Inbox、Go Fucking Do It、Tubelytics 等项目要么不赚钱，要么增长停滞，几乎消耗掉一整年的积蓄与精力，在公开博客和访谈中他提到，当时有过“是否应该放弃独立产品”的犹豫。
他的解决方式一方面是从这些失败项目中抽象共同的技术资产和经验，比如自动生成视觉内容的需求和相应的技术栈，另一方面是在意识到 Bannerbear 有更强迹象时，把精力集中到这一个产品上，停止继续做更多新项目，从“多点试探”转向“聚焦一个跑通的方向”。
第一，“工具产品 API 化”的思路具有很强的可迁移性，许多面向终端用户的中国工具（如图片编辑、数据处理、报表生成、语音合成等）都可以抽象出底层能力，以 API 或 SDK 形式提供给其他产品团队使用，让客户在自己的产品里集成这些能力，而你不必承担前端 UI 和多端适配的复杂度。
第二，“一周编码、一周营销”的 50/50 节奏同样适用于国内独立开发者，很多人要么长期闷头写代码，要么沉迷流量玩法而忽视产品本身，给自己每两周设一个明确的切换节奏，在技术和市场之间来回调整，可以帮助你既保持产品演进，又不断验证真实需求和获客渠道。
第三，针对开发者群体做 Build in Public 在中国也有空间，只是载体从 Twitter 换成了小红书、即刻、V2EX、知乎专栏等，你可以公开分享产品演进、技术选择和小规模收入节点，在保证合规和安全的前提下，让潜在用户看到“一个稳定在迭代的工具”，而不仅是一则冷冰冰的广告。
支付和结算方式需要适配本地环境，Bannerbear 使用 Stripe 收款并以美元计费，而在中国，你更可能需要接入微信支付、支付宝企业收款或银联通道，必要时考虑对内人民币计价、对外美元计价的双轨体系，以及为企业客户提供发票和合同流程。
营销渠道上，Product Hunt 和 Twitter 的作用在国内有限，你需要根据目标人群选择合适场域，例如面向前端和全栈开发者时可以重点经营 V2EX、少数派、掘金专栏，面向运营或内容从业者时可以在小红书、公众号和视频号做教程内容，把“自动化解决方案”讲清楚，再引导有能力的团队接入 API。
技术和文档方面，Jon 使用 Ruby on Rails 这一在国内相对小众的栈，而你可以根据本地人才供给选择更常见的 Node.js、Python（如 FastAPI）、Go 等，并保证中文开发文档清晰易读，必要时提供 SDK 或封装好的示例项目，降低国内团队的集成门槛。
完全公开收入仪表板的做法在中文语境下需要谨慎，Jon 早期采用 Open Startup 模式公开 Bannerbear 的 MRR，但随着规模和环境变化，他在 2024 年前后选择下线这部分内容，在国内环境中，过于细致地披露收入和客户信息可能带来不必要的风险或舆论干扰，更现实的做法是适度分享增长节奏或区间数据，让用户感受到产品的“在持续运转”，而不必追求极端透明。
他用到的核心工具可以分为基础设施、支付、分发和集成几类。
1. Heroku / 云服务平台
2. AWS S3 等对象存储
3. Cloudflare
4. Stripe
5. Zapier / Make.com 等自动化平台
如果你想在中国复制类似的模式，可以按以下三步执行。
☑️ 第 1 步（本周）：界定“一个你熟悉的技术痛点＋合适的用户”
☑️ 第 2 步（第 2–4 周）：做出可收费的 API MVP 并找到首批试用者
☑️ 第 3 步（第 1–3 个月）：建立“50/50 节奏”和基础商业模型
Jon Yongfook 的 Bannerbear 告诉我们，一个设计师出身的独立开发者可以通过将工具产品 API 化、聚焦 B 端自动化场景，在没有融资的前提下，把一个项目做成年收入约 60–90 万美金的小而美生意。
可复制的关键不在于具体的图片或视频生成能力，而在于敢于从失败项目中抽象出共性痛点，敢于为 API 设定足够合理的价格，并长期坚持“半周写代码、半周做内容”的节奏，让产品在技术和市场两侧同时成长。
对中国创业者而言，重要的是找到一个你既有技术积累又有真实需求的垂直领域，选择以 API 而非终端工具切入，用合适的本土化渠道和支付体系慢慢滚大，而不是一开始就幻想成为下一个估值几十亿的独角兽。
专栏作家
陆晨昕，公众号：晨昕资本论/晨昕全球Mkt ，人人都是产品经理专栏作家。资深媒体人，创业者，专注于科技&互联网&内容&教育行业深度研究。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Pixabay，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。