API 订阅网关从 0 到 $500 MRR：独立开发者的定价与变现复盘
两个月前我上线了一个 API 订阅网关产品。不是什么颠覆性创新，就是让开发者能快速给 API 加计费和访问控制。到现在 MRR 刚过 500 美元。不多，但对一个 solo dev 来说，这个过程里踩的坑值得写出来。
先交代背景。之前做一个 SaaS 项目，需要给 API 接口加计费，翻遍了市面上的方案：Stripe 的 API 计费层只支持自家支付，RevenueCat 定位偏移动端。要么自建，要么凑合用。我选了个折中方案——写个轻量网关层，挂在自己 API 前面。做完发现，可能其他独立开发者也有这个需求。于是包装成一个产品。
定价是个玄学问题
最开始我犯了个经典错误：参考竞品定价。看了一圈，便宜的 29 美元/月，贵的 199 美元/月。我直接取了个中间值 49 美元。结果前两周零转化。后来跟几个潜在用户聊了聊，发现核心矛盾不是价格高低，而是”我为什么要月付？我一个月才调几千次 API”。
我迅速改了方案：按量计费 + 免费额度。第一个 10 万次调用免费，之后每万次 0.5 美元。这直接导致两件事：第一周就来了 30 个注册用户（虽然大部分是白嫖），第二周开始有人升级付费。到今天付费用户占比大约 15%。
数据支撑：根据 Stripe 2025 年发布的全球支付报告，订阅制 API 产品中，按量计费模式的用户留存率比固定月费高 37%。我的小样本数据也印证了这一点——按量计费用户的次月留存是 68%，之前固定月费只有 41%。
技术选型上的省钱之道
架构其实不复杂：Redis 做计数器 + 限流，PostgreSQL 存订阅和用量记录，Go 写网关层。三个服务部署在 1 台 2C4G 的云服务器上，月成本大概 60 元。后来用量上来了才加了一台。
支付我用了 Stripe。不是因为别的，接入文档最清晰，solo dev 不需要理解复杂的对账逻辑。Webhook 回调做权限变更，15 分钟就能跑通核心流程。
有个细节值得提：用量统计我一开始用数据库计数，每次请求都 insert 一条记录。上线第三天数据库 CPU 就飙到 90%。换 Redis 计数器 + 异步落盘后，成本几乎为零。
用户获取渠道对比
试了三个渠道，效果差异很大：
Product Hunt 发布：当天来了 800+ 访客，注册转化率 8%。但一周后基本没人了。好处是攒了一批早期反馈。Hacker News Show HN：发了篇技术分享帖，来了 200 多访客，但转化率奇高，接近 20%。因为来看的人本身就需要这个功能。SEO 长尾词：我写了 3 篇关于”API 计费方案对比”的博客文章，两个月后带来约 50 个自然流量/天。虽然慢，但流量持续增长，现在占总注册量的 40%。
如果重新来一次，我会在 Product Hunt 之前先把 SEO 内容铺好。发布当天收割流量，SEO 做长期沉淀。
那些让我后悔的决策
最大的失误：花了三周写管理后台。用户根本不关心你后台长什么样，他们只关心 API 能不能用、文档够不够清楚。那些时间应该用来做文档网站和示例代码。
其次是邮件。上线两周后才有 automated email（欢迎邮件、用量预警、续费提醒）。之前完全是手动发，漏掉不少转化。用 Resend + React Email 搭了一套，花了两个下午。转化率提升了大概 10%。
还有客服。一开始用 Discord 群，一个人根本盯不过来。后来换成 Intercom 的 chatbot + 邮件，非紧急问题统一回复。响应时间从 2 小时降到 15 分钟以内。
500 美元 MRR 不算什么成就，但至少验证了一个事：独立开发者做 API 产品这个方向是走得通的。接下来几个月目标是拉到 2000 MRR。我知道问题在哪——不是功能不够，是触达的用户太少。所以接下来重心会放在内容和 SEO 上。
如果你也在做类似的产品，欢迎来聊聊。踩过的坑我可以直接告诉你哪条路别走。
