小产品，
也可以是一门生意。

EDITOR'S PICK

Tally：一次受挫的旅游创业，最后做成了表单工具

Tally 并不是从一份“表单市场分析”开始的。两位创始人先做旅游业务，疫情后失去客户，才转向一个他们自己嫌贵、嫌难用的老品类。

Photopea：从“能不能在浏览器打开 PSD”开始的十多年

Photopea 没有先做“网页版 Photoshop”。它最早只是一个 PSD 文件查看实验，功能一项项长出来，六年后才真正让创作者不必去找工作。

Simple Analytics：不想再装 GA，怎么变成一个产品

Adriaan van Rossum 做客户网站时反复安装 Google Analytics，却越来越不喜欢这种数据收集方式。产品机会不是调查出来的，而是从自己的职业摩擦里长出来的。

Buttondown：先给自己做一个顺手的工具，再慢慢把它变成生意

Justin Duke 没有因为“邮件工具很多”就放弃。他只是觉得现有产品太重，先做了自己愿意用的版本，几年后才从业余项目变成全职公司。

Plausible：324 天才到 400 美元 MRR，后来发生了什么

Plausible 的早期增长并不快。创始团队公开复盘过：从第一个付费用户到 400 美元 MRR 用了 324 天，而真正的转折来自一篇击中用户立场的文章。

EDITOR'S PICK

Carrd：一个功能不多的建站工具，为什么低价反而是生意的一部分

Carrd 没有和 Wix、Squarespace 比谁功能更多，而是把产品压到“一页网站”这个范围。低价不是促销动作，而是和产品复杂度、获客方式、用户预期一起设计的。

Tally：把 99% 功能放进免费版，为什么不一定是在亏钱

Tally 的免费层不是传统“阉割版试用”。大量功能和提交量免费，真正收费的是品牌、团队和企业控制能力。关键不是大方，而是免费用户会帮助产品继续分发。

Photopea：免费浏览器工具靠广告赚钱，真正成立的条件是什么

广告模式不是“有流量就能赚钱”。Photopea 的特殊之处在于重计算主要发生在用户设备、使用时长长、免费价值完整，才让广告和 Premium 有机会共同成立。

Plausible：代码都开源了，为什么用户还愿意按月付费

开源并不会自动毁掉 SaaS 收费。Plausible 把“你可以自己部署”和“我们替你稳定托管”同时摆在桌面上，卖的不是代码访问权，而是省事、持续维护与产品信任。

Buttondown：小团队做邮件 SaaS，为什么还要提供真人服务

邮件工具的表面功能很容易复制，真正麻烦的是投递、迁移、域名、数据和长期支持。Buttondown 把克制的产品、按需付费和人工服务组合在一起。

市场已经很拥挤了，还值不值得做？先看所有产品是不是都在往同一边走

竞品多不等于机会消失。Tally 和 Buttondown 都进入了成熟老市场，它们找到的不是“没人做”，而是主流产品不断变重后留下的一群用户。

隐私和规则变化，怎么从“合规成本”变成新的产品机会

Plausible 和 Simple Analytics 都不是因为分析软件消失了才出现，而是用户开始对追踪方式产生新的要求。规则变化会增加成本，也会重写用户的购买标准。

Chrome 扩展、Shopify App：为什么平台生态适合做小产品

平台生态替开发者解决了一部分分发和身份问题：用户已经在那里、安装路径已经存在、需求也更具体。但平台同时拥有规则、审核和抽成权。

EDITOR'S PICK

从搜索词反推产品：别先想功能，先看用户已经在主动找什么

搜索不是只用来做 SEO。一个人把问题打进 Google 时，已经表达了主动需求。关键词真正有价值的地方，是帮助你区分“有人讨论”和“有人正在找解决方案”。

找 AI 产品机会，先找“重复而且能验收”的工作，不要先找聊天框

AI 很容易把任何产品都变成一个输入框。更扎实的机会通常来自一条已经存在的工作流：步骤重复、判断耗时、结果还能被检查。

MVP 第一版到底要不要做登录？先看它是不是核心任务的前提

登录很容易被当成“正式产品标配”，但它会带来账户、邮件、密码恢复、数据删除和安全责任。第一版要不要做，应该从核心任务是否需要身份连续性判断。

EDITOR'S PICK

让 AI 写代码之前，先把任务写成一份能验收的施工单

“帮我把支付做好”不是开发任务。AI Coding 更稳定的前提，是把现状、边界、业务规则、禁止事项和验收条件写清，让模型知道什么叫完成。

Build 通过不等于能上线：小产品至少要过哪几层验收

构建成功只证明依赖和代码能产出部署包。登录、支付、数据库迁移、权限和真实浏览器流程仍可能全部有问题。验收应该一层层缩小“不确定”。

域名、DNS、SSL、部署是什么关系？上线时别把四件事混在一起

域名是名字，DNS 决定名字指向哪里，部署平台真正运行代码，TLS/SSL 负责 HTTPS 身份和加密。四层任何一层错了，用户都可能只看到“网站打不开”。

第一次接支付，最难的不是付款按钮，而是重复请求、回调和状态

支付会遇到超时、重试、异步回调和重复事件。真正可靠的系统必须做到同一个业务动作不会被执行两次，并且不能把“用户跳回成功页”当成到账事实。

EDITOR'S PICK

SEO 到底在做什么：让一个真实需求落到一个最合适的页面

SEO 最容易被做成关键词密度和批量发文。更稳定的起点是把搜索词还原成用户任务，再让站点结构、页面内容和技术信号共同说明“这个页面解决什么”。

一个关键词该做一个页面还是多个页面？先看用户是不是在做同一件事

页面数量不该由关键词数量决定。近义词可能属于同一搜索意图，同一个词也可能包含不同任务。拆页之前，先比较结果页和用户最终想得到的东西。

新网站上线后 Google 为什么搜不到？按抓取、索引、排名三层排查

“搜不到”可能是 Google 还没发现页面、发现但没有索引，或者已经索引却排得太后。三个问题的排查方法完全不同，先用 Search Console 判断处在哪一层。

外链有没有用？先把“真实推荐”“可提交入口”和垃圾链接分开

链接能帮助用户和搜索引擎发现站点，也可能形成推荐信号，但不是所有外链都等价。批量自动制造链接、付费传递排名权重和低质目录，反而属于 Google 明确列出的风险行为。

Product Hunt、Reddit 冷启动：别把发布日当流量抽奖

发布平台可以带来第一批真实用户，但“扔个链接等爆”通常没用。Product Hunt 重视完整 Launch 页面和社区互动；Reddit 对自我推广和垃圾行为有明确规则。

EDITOR'S PICK

隐私政策别从模板开始：先把网站到底收了什么数据画出来

隐私政策不是页脚装饰。注册、分析、支付、日志和 AI 服务会把数据交给不同系统。先做真实数据清单，才知道应该向用户说明什么。

Cookie Banner 不是越大越合规：先分清哪些存储真的需要同意

登录会话、安全和购物篮等严格必要技术，与广告追踪、行为分析不是一回事。先做 cookie inventory，再决定哪些能直接设置、哪些必须等用户选择。

为什么不能照抄同行的 Terms：你的收费和退款规则不一样

服务条款是交易规则，不是免责声明仓库。产品卖什么、什么时候交付、怎么续费、怎样取消、什么情况下退款，都应该和代码及购买页面一致。

删除账号不是删一行 users：数据、订单和备份怎么办

账号、内容、日志、支付、发票、客服和备份往往分散在不同系统。删除功能要先建立数据地图，并区分可以立即擦除的个人数据与有合法保留理由的记录。

订阅不是一个 isPro：续费失败、取消和恢复都会让状态变复杂

订阅系统如果只存“是否会员”，很快会遇到现实：用户已取消但本周期仍有效、扣款失败进入宽限期、恢复订阅、退款和 Provider 回调重复。