这是
content/posts/indie/indie-first-100-days的目录页，收录 10 篇文章。前面六组分别讲「要不要做」（生存指南）、「在哪卖」（平台寄生）、「丢了怎么找回」（资产韧性）、「怎么合法立住」（主体合规）、「多条线怎么加减」（产品线）、「怎么用接单换现金」（服务生意）。这一组回到最原始的一段：你手上的想法，怎么在有限的时间里变成一个有人用、有人付钱的东西。
这个系列解决什么问题
大多数独立开发者的第一个产品不是失败在「做不出来」，而是失败在没有出口条件：做到一半觉得不够好，于是加功能；上线之后没人用，于是换渠道；有人用了但不付钱，于是降价；降价之后还是不付钱，于是再换一个想法。一年过去，手上留下四个半成品。
问题不在于能力，而在于没有一条能被打断的路径。这条路径至少要回答：
- 什么时候算「做完了这一段」，凭什么判断？
- 现在该去找人聊，还是该写代码？
- 有多少时间可以花，花在哪几段？
- 什么信号出现时应该继续，什么信号出现时应该停？
- 拿到第一批用户之后，怎么判断他们是真的要用，还是只是给了面子？
这组文章把 0→1 拆成四个里程碑和十个阶段，每阶段写清实验出口、适用硬门槛、交付物和工时预算。判据没达成，就退回上一阶段补证据，而不是往下加功能。
核心主张：100 天不是工期，是验证的时间盒
100天是可调整的验证窗口；能否作决定取决于证据、自然使用周期与预算，不保证成熟产品或市场结论。
由此有三条原则：
- 每个阶段写清出口判据与硬门槛。 主要实验目标与法律、安全、合同条件同时检查，不能为了单一目标略过必要条件。
- 先卖结果，再卖软件。 手工交付验证结果需求与流程，技术速度、规模和精度另做实验，不把人工失败当软件必然失败。
- 时间盒优先于完整度。 第 100 天必须给出「继续 / 转向 / 止损」三选一，不能以「再给我两个月」结束。
10 篇速览
| # | 文章 | 解决的问题 | 交付物 |
|---|---|---|---|
| 01 | 「1」是什么：四个里程碑与一张 100 天账本 | 怎么定义 0→1 的终点与阶段出口 | 里程碑表 + 100 天账本 |
| 02 | 第 1–10 天：选题与付费证据 | 做什么题、凭什么说有人会付钱 | 问题清单 + 问题投入A/B/C + 本方案成交表 |
| 03 | 第 11–20 天：十次对话 | 怎么问、问谁、怎么把话变成结论 | 访谈脚本 + 记录表 + 结论页 |
| 04 | 第 21–30 天：手工跑通一次交付 | 不写产品，先人工交付一次 | 手工交付 SOP + 结论表 |
| 05 | 第 31–50 天：主路径 MVP 的范围 | 砍到什么程度才算能上线 | 一条主路径 + 不做清单 |
| 06 | 第 51–60 天：十人封闭测试 | 怎么在没有数据时发现可用性问题 | 任务脚本 + 观察记录 + 问题分级 |
| 07 | 第 61–70 天：上线前的十五件事 | 上线必须有什么、可以没有什么 | 上线清单 + 最小支持通道 |
| 08 | 第 71–80 天：发布与第一周 | 发布日做什么、第一周看什么 | 发布动作表 + 第一周看板 |
| 09 | 第 81–90 天：反馈分诊与第一次收费 | 意见怎么分类、免费怎么变付费 | 分诊表 + 定价页 + 涨价路径 |
| 10 | 第 91–100 天：复盘与判据 | 继续、转向还是止损 | 三个数 + 决策页 + 下一个 30 天 |
三条阅读路径
路径 A：还没有具体想法
02 → 03 → 04 → 01
先找证据，再定终点。适合「想做点什么，但说不清做什么」的状态。
路径 B：已经做了一半，上不去也停不下
01 → 05 → 06 → 07 → 10
适合代码写了一堆、没人用、也不知道该继续还是该停的项目。
路径 C：马上要上线
07 → 08 → 09 → 10
适合功能基本可用、只差发布与收费这一段的产品。
与其它专题的边界
| 专题 | 讲什么 | 与本组的区别 |
|---|---|---|
| 独立开发者生存指南 | 要不要做、怎么活过 12 个月 | 方向、心态与节奏；本组是启动之后的执行顺序 |
| 独立开发者的平台寄生 | 在哪个渠道卖、怎么过审 | 渠道与上架规则；本组讲上架之前做什么 |
| 独立开发者的资产韧性 | 账号、数据与恢复 | 出事怎么找回；本组只列上线必须有的最小项 |
| 一个人的公司 | 主体、税务、合同与知识产权 | 法务与申报侧；本组不展开条款细节 |
| 一个人的产品线 | 第二个产品与组合运营 | 多个产品之间怎么加减；本组只做第一个 |
| 一个人的服务生意 | 接单、报价、交付与产品化 | 卖自己的时间；本组卖可重复的产品 |
| SaaS Starter | B2B SaaS 的客户发现与销售推进 | 有销售动作的订阅产品；本组面向个人工具、扩展、桌面与微型产品，按时间序列组织 |
| 一个人让产品被看见 | 发布之后的渠道、转化与归因 | 逐渠道规则与账本；本组是 100 天时间盒内的流程 |
| 一个人把价格定对：定价、付费墙与涨价 | 定价账本、套餐、付费墙与涨价路径 | 100 天内的第一次收费；本组讲收费之后的定价结构与实验 |
| 一个人把用户留住 | 发布之后的留存、流失与续费 | 100 天之后的长期运营；本组只到第 100 天的复盘 |
本系列围绕“有人用、有人付钱、有使用留存证据”安排有限实验，并在第100天作投入决定；尚未走满观察期的项目，应明确未知及下一检查日，不保证100天内必然得到全部证据。
本组统一计算口径
- 问题投入用A/B/C：A可核实既有金钱支出，B具体行为/时间投入，C态度或待核实线索。竞品付款不等于本产品成交。
- 本方案状态另记意向/预算、预付待履约、已交付未退款、退款/争议；软件与前期服务分别统计，重复订单按独立购买主体去重。
- 工时按14周、每周5工作日：半职20小时共280，全职40小时共560；99–100天日历缓冲。各阶段工作日与上限见01篇，任务估算超过上限先减范围或延期。
- 排期第68天预热准备、第69–70天休息，第71天发布、第72–78天首周观察；提前工作的工时只计一次。
- 使用留存按本例首次付费获得权益起算，第28–34天有核心任务算留存；第100天时入组≤66才成熟，晚入组标未成熟，失联/缺日志标未知。
- 推荐、复购、续费与使用分开。买断仍可测使用留存；低频工具按自然周期另定窗口。
- 转化用同队列人数、固定事件与完整观察窗；订单频次、退款及现金另记，设备估计不冒称精确人数。
- 现金贡献与时间经济差额分开，自有工时估值不是银行支出。法律/安全硬门槛不能按“能收钱”决定后置。
本组阈值、比例与工时为教学输入；官方资料只支持其对应规则和适用条件。具体场景和可复算示例见各篇。
使用说明
- 文中的项目、用户、报价和数字都是教学假设，人物、引语与结果不代表经核实的真实案例。
- 本系列不构成商业、法律或税务意见。主体、发票、条款请回到一个人的公司 并按实际情况咨询专业人士。
- 每篇的清单与模板可以直接改成自己的文档，但不要直接把教学数字当成本项目的目标值。
- 100 天是可替换的时间盒；换成长度不同的窗口时，请同步改阶段预算与出口判据，不要只改标题。
本组的证据与使用方法
正文把教学假设、经验判断与官方规则分开标注。每篇末尾给出该阶段的验收方式与可复算示例；里程碑阈值、转化比例与工时预算都是演示输入，须按自己的项目重算。涉及真实用户数据、收款与合同的操作，仍以实际环境与适用规则为准，不能用目录页摘要代替正文条件。