独立开发者最大的错觉

独立开发者最大的错觉

我们以为自己在做产品, 其实大部分时间在做自我感动
独立开发者 (Indie Hacker) 社区有一种很强的叙事: 一个人, 一台电脑, 一个好想法, 就能改变世界. 这个叙事很鼓舞人心, 也很危险. 因为它让我们相信了一些不太真实的东西.
我踩过这里面的每一个坑.

错觉 1: "只要产品好就能卖出去"

这是独立开发者最大的, 最致命的错觉.
"Build it and they will come" -- 现实是: Build it and nobody will notice.
StellarMail 前三个月, 90% 时间写代码, 10% "顺便" 推广. 结果: 功能越来越多, 用户数纹丝不动.
后来调整为 50% 做产品, 50% 做营销 -- 写博客, Twitter 分享, 冷邮件, Reddit 回答问题. 用户才开始慢慢增长.
⚠️
Marketing 不是产品做完之后的事, 是从第一天起就应该做的事. 市场上有大量 "产品一般但营销很好" 的成功产品, 也有大量 "产品很好但没人知道" 的失败产品.
对独立开发者有效的营销手段:
  • Build in public: 在 Twitter/X 上分享建设过程, 包括失败和困惑
  • SEO + 长内容: 写 "如何解决 XX 问题" 而不是 "我们产品多好"
  • 社区参与: 去目标用户聚集的地方提供价值
  • 邮件列表: 从第一天开始收集, 这是你唯一 "拥有" 的分发渠道

错觉 2: "我要做一个完美的 MVP"

MVP 的 "M" 是 Minimum, 不是 "Magnificent".
我做 Stitch 时花了大量时间做 CloudKit 同步, StoreKit 2 订阅, 完整的内容管理系统... 然后发现, 真正需要验证的只有一个问题: "家长愿不愿意用 AI 讲故事 App?" 这用一个 landing page + waitlist 就能验证.
完美是交付的敌人. 我现在的原则: 第一版产品丑到自己都不好意思, 才说明你发布得够早.
StellarMail 第一版连模板编辑器都没有, 用户需要自己写 HTML. 很简陋? 是的. 但它足以验证核心假设.

错觉 3: "MRR 是唯一指标"

独立开发者社区有 MRR 崇拜. 但 现金流比 MRR 更重要.
一个 MRR $500 但每月花 $600 的项目, 不如一次性卖了 $2000 课程的项目.
StellarMail MRR 增长很慢, 但同时有 AIHack.io 知识付费, Chrome Extension 一次性收入, 和技术咨询收入. 加在一起现金流是正的.
比 MRR 更值得关注的指标:
  • Runway: 还能撑多久?
  • Net cash flow: 实际到手 - 实际支出
  • Revenue per hour: 每小时投入产出比

错觉 4: "我需要更多功能"

大多数 feature request 不是 "用户需要这个功能", 而是 "用户遇到了障碍, 他以为加一个功能就能解决".
StellarMail 早期, 用户要 drag-and-drop 邮件编辑器 (开发成本一个月). 真正的问题是 "我不会写 HTML". 解决方案: 提供预制模板. 两天搞定.
每加一个功能, 就增加一分维护成本. 我的处理流程: 先感谢反馈, 问清 "解决什么问题", 找更简单的方式, 三个以上用户提同一需求才考虑做.

错觉 5: "技术栈越新越好"

稳定远比新潮重要. StellarMail 用 Next.js 14, 没升级 15 -- 因为 14 跑得好好的, 用户不关心你用什么版本.
我的技术选型原则:
  • 选你最熟悉的, 不是最好的
  • 选社区最大的
  • 选最无聊的 -- boring technology wins
  • 不在生产环境尝鲜
我的技术栈: Next.js + Supabase + Cloudflare + Contabo VPS. 不是最新潮, 但稳定, 社区大, 20+ 服务月成本 < $50.
错觉 vs 现实对比
错觉 vs 现实对比

我踩过的最大的坑

2024 年初, 同时做三个项目, 每个都推进了一点, 每个都没推进到位. 两个月后: 三个项目, 产出为零.
问题: 完美主义 + 多线程 = 什么都做不完.
后来改为: 一次只推进一个项目, 推到可发布的最低标准就发布. 不完美没关系, 先让它存在于世界上.

真正重要的事

  1. 验证比构建重要 -- 先确认有人愿意付钱
  1. 分发比产品重要 -- 营销时间不应低于开发时间
  1. 速度比质量重要 (在早期) -- 完美的产品是迭代出来的
  1. 现金流比增长重要 -- 活着才能继续做
  1. 减法比加法重要 -- 刭功能, 刭项目, 刭不必要支出

关键思考

你花在营销上的时间占总工作时间多少? 低于 30% 就该警惄了
你现在手上有几个 "做了一半" 的项目? 能不能砍掉一些?
你最近一次拒绝用户的 feature request 是什么时候?
如果只看现金流, 你的项目组合是正的还是负的?