别从零发明需求：独立开发者的「替代品」机会
独立开发最贵的一步，越来越不是把软件写出来，而是确认一件事：做出来以后，到底有没有人要。
AI 编程把 MVP 的成本继续往下压。过去需要一个小团队做几个月的东西，现在一个熟练开发者可能几天就能搭出可用版本。实现能力因此越来越像基础设施，选什么需求、从哪里拿第一批用户、为什么有人愿意从现有产品迁过来，反而变得更值钱。
这里有一条经常被低估的路：不要总从零发明需求，去成熟软件旁边找正在逃走的用户。
这类产品通常会被笼统地叫作”仿品””平替”或者 “X alternative”。这个词容易让人想到像素级复制、换个名字上架、功能少一点然后卖便宜一点。那种做法商业质量通常不高，还会碰到品牌、知识产权和应用商店审核风险。
真正值得复制的是已经被验证的需求，不是原产品本身。
一个成熟产品已经替后来者完成了很多最昂贵的工作：它教育过用户，验证过有人愿意为这个任务付钱，形成了搜索词、社区、教程、工作流和历史数据。后来者需要找的，是这些用户正在被迫忍受什么，以及原厂为什么一直没有解决。
如果这个缺口来自平台战略、收费结构、产品架构、组织包袱或者一次停服和强制迁移，它就可能成为独立开发者非常舒服的切入口。
两个小经历，正好把边界画了出来
我自己走过一次很完整的”寻找替代品”路径。
我长期用滴答清单。之前因为不太想继续付费，试过价格便宜很多的一木清单。表面看，两边都能建任务、做清单、设提醒，功能列表并没有隔着一个时代。我确实迁过去用了一阵，后来还是觉得体验有差距，又回到了滴答清单。
这件事对做产品很有启发。
价格不满会制造试用，不一定会制造留存。
成熟 Todo 工具真正难复制的部分，常常不在官网那张 feature checklist 上。任务能不能瞬间记进去，通知稳不稳，重复规则有没有奇怪边界，同步会不会偶尔打架，Widget 是否顺手，几个平台之间是不是一个脑回路，这些细节都是用了几个月以后才开始显形的。
“便宜版滴答清单”看起来需求已经验证，实际却会掉进一个很深的坑：最容易做的是前 80%，真正决定长期迁移的可能是最后 20%。而这 20% 恰好最费时间。
另一个经历正好相反。
我在 Android 手机上装过一个类似 BlockyTime 的时间记录工具。BlockyTime 的核心交互很鲜明：它不要求用户每次开始工作都点 Start、结束再点 Stop，而是把时间切成块，之后快速回填自己做了什么。它的 App Store 页面写明自己曾获 2016 年中国区推荐；直到现在，它仍然主要存在于 Apple 设备上。BlockyTime 的 App Store 页面也把”不需要 Start/Stop”作为核心卖点。
Android 用户怎么办？AlternativeTo 的 BlockyTime 页面专门列出了一个 Android 替代品 Blocks Time Tracker。这个页面目前甚至只列了这一项 Android alternative。
这里的切口比”便宜一点”强得多。
用户已经认可一种具体工作流，只是原产品不在他的设备上。需求教育、产品概念，甚至”我想要什么”的描述都已经存在。后来者解决的是一个非常明确的断裂：我喜欢 X，但我用不了 X。
这类需求会自然长出 X for Android、X for Windows、X for Linux 这样的搜索词。对独立开发者来说，这几乎等于用户自己写好了第一版 PRD。
好的替代品机会，通常有三个条件同时出现
把这些案例摆在一起，我现在更愿意把”替代品”理解成一种市场进入方式，而不是一种产品类型。
第一个条件是已经存在足够多的用户。原产品越成熟，往往意味着需求教育越充分。你不需要解释”为什么人类需要一个表单工具””为什么网站需要统计””为什么有人要稍后阅读”，这些问题别人已经花了很多钱帮你回答。
第二个条件是用户有明确的逃逸理由。可能是价格越来越高，某个平台一直没有客户端，产品不断塞入自己不需要的 AI，隐私和数据所有权不符合要求，核心功能被砍掉，或者产品干脆要关了。最好不是一句”这个产品不够完美”，而是一件会驱动真实迁移的事。
第三个条件最重要：这个差异不能太容易被原厂顺手抹掉。
一个按钮、一套主题、便宜 20%，都很容易被复制。反过来，如果差异来自”我们只做本地，不做云端””我们不靠收集行为数据挣钱””我们只服务 Android，而原厂长期绑定 Apple 生态””我们把一套巨型平台砍到只剩一个高频任务”，原厂要跟进就可能需要改变自己的产品方向、收入结构或者技术架构。
这才是比较舒服的位置。
Tally：表单早就是红海，照样能长出 500 万美元 ARR
表单工具很适合拿来反驳一种常见直觉：一个品类只要有 Google Forms、Typeform 这样的成熟产品，就已经没有新公司的位置。
Tally 2020 年进入这个市场时，表单当然不是新需求。它做的事情反而很”老”：让人创建表单、收回复。
差别来自几个地方同时发力。
Tally 把编辑器做得更像写文档，用户直接输入内容，而不是不断在传统表单配置器里添加字段。它的免费策略也非常激进，官方 FAQ 至今写着可以免费创建无限表单并收集无限响应。同时，它还提供Typeform 一键导入，让已经积累了一堆表单的用户不必从零重建。
到 2026 年 4 月，Tally 官方披露已经跨过 500 万美元 ARR，团队 11 人，仍然完全 bootstrap。这篇官方复盘很值得独立开发者看。
这个案例真正有价值的地方，不是”Typeform 太贵，所以便宜就能赢”。Tally 同时改了收费边界、编辑体验和迁移摩擦。它借用了一个被验证得不能再验证的需求，但重新选择了自己要服务的用户和产品边界。
这比从零创造一个”新时代表单品类”稳得多。
Plausible：对手免费，而且功能比你强，也不等于没机会
Plausible 的案例更极端。
它面对的是 Google Analytics。Google Analytics 不只是成熟，而且免费，功能、生态和品牌都远强于一个小团队。
Plausible 没有试图在功能数量上赢。它把自己放在另一个坐标里：简单、轻量、开源、privacy-friendly。2022 年，Plausible 官方披露做到 100 万美元 ARR，当时团队只有 4 人，有 7000 多个付费客户，并且保持独立、盈利和 bootstrap。官方复盘还提到，欧洲围绕 Google Analytics 的监管事件进一步放大了隐私型替代方案的需求。
这是很典型的结构性分叉。
Google 当然有能力做一个更简单的统计面板，也有能力写一个隐私设置页面。但 Plausible 的位置并不只是一块面板，它连开源、自托管、数据控制和公司的产品哲学都绑在一起。大公司的能力很强，不代表它愿意为了某一小群用户改变整套方向。
独立开发者真正能利用的，往往就是这种”不值得大公司转身”的缝。
最值得扫的，是几类反复出现的裂缝
“找一个热门软件，照着做”太粗了。更有效的办法，是固定去找几种结构变化。
平台缺口
BlockyTime 是很小的例子，Things 是更典型的例子。
Cultured Code 直到现在仍在官方文档里明确写着：如果你主要使用 Windows 或 Android，没有办法直接在 Things 里创建任务；官方建议借助 Microsoft To Do、Apple Reminders 或 Mail to Things 绕过去。Things 的支持文档把这个缺口写得非常直接。
这类机会的好处是用户意图非常清楚，坏处是原版如果哪天补平台，核心差异可能突然消失。所以做之前要判断：原厂只是暂时没做，还是它的团队、技术栈和品牌长期都在押注某个生态。
付费模型的分叉
订阅改买断、按席位改按用量、云端订阅改 BYOK，都可能形成机会。
但这里最容易犯错：把”用户嫌贵”理解成”用户会给另一个产品付钱”。前面滴答清单的经历已经说明，用户完全可能抱怨价格、试遍替代品，最后还是回去继续付费。
所以价格最好和另一个结构性差异绑定在一起。纯本地工具可以用买断，因为后续边际成本低；AI、存储、视频处理这类持续产生服务器成本的产品，如果拿 lifetime 当唯一卖点，很容易把未来维护成本提前卖光。
大产品里的一个高价值子任务
另一种路线是主动做减法。
Screen Studio 没有把自己做成另一个包罗万象的视频平台。它围绕”快速录出漂亮的产品 Demo 和教程”做自动 zoom、平滑鼠标、录制后调整 cursor、背景和版式。官方产品页甚至直接把自己描述成一个 opinionated screen recorder。
这里的机会来自大产品越做越臃肿以后留下的一群人：他们只用其中 10% 的能力，却必须承担剩下 90% 的复杂度。
这种产品往往更适合独立开发者，因为范围小，体验反而可以做深。
架构分叉
cloud → local、hosted → self-hosted、closed → open、平台拥有数据 → 用户拥有数据、内置昂贵 AI → BYOK，这些都是近几年很值得盯的方向。
它们的共同点是，差异已经进入软件架构和商业模式。原厂即便看到你，也很难用下个版本加一个 checkbox 就完全抹平。
当然，”local-first”三个字本身不是需求。用户仍然要有具体理由：更低延迟、离线可用、敏感数据不上传、长期成本可控，或者能够接入自己的模型和基础设施。
停服、收购和强制迁移
这一类机会强度很高，而且有明显的时间窗口。
Screenhero 被 Slack 收购、原有 pair-programming 产品消失以后，Tuple 就明确承接了这批用户。Indie Hackers 对这段历史的整理称，Tuple 在完整产品还没正式开放时就拿到了约 8000 美元销售额，后来收入达到数百万美元级别。这份二手案例不能拿来证明整个行业有多大，但足以说明一个机制：当用户喜欢的产品被拿走时，”我要原来的东西回来”本身就是需求。
格式和工作流兼容
用户选择软件以后，真正把他锁住的常常不是品牌，而是多年积累的文件、数据、快捷键、插件和肌肉记忆。
这意味着迁移能力本身就是产品功能。
能读旧格式、能导入历史数据、能保留原来的快捷键和主要工作流，往往比”多三个 AI 功能”更能推动切换。Tally 做 Typeform importer，就是很直接的例子。
因此看到一个成熟软件时，我会额外问一句：它留下了什么用户资产，可以成为后来者的兼容入口？
为什么我不太看好”功能差不多，价格便宜一半”
这种产品当然可能赚钱，但它通常不是我会优先下注的方向。
第一，价格是最容易被竞争对手复制的差异。你能降，对方也能做促销，也能推出轻量套餐。
第二，价格用户往往最敏感，忠诚度却未必最高。今天因为你便宜迁过来，明天也可能因为另一个产品更便宜继续迁。
第三，成熟软件的隐藏复杂度很容易被低估。Todo、笔记、日历、密码管理、项目管理都属于这种类别：两周做出看起来像样的 MVP 没问题，用两年把同步、迁移、通知、权限、插件和边界情况磨平则完全是另一回事。
所以一个看起来很诱人的问题——“滴答清单这么贵，我做个半价版行不行？”——其实信息量不够。
更有价值的问题是：
哪一群滴答清单用户正在因为什么具体原因离开？这个原因是价格，还是某个平台、某套工作流、某种数据控制方式？我能不能只接这一群人，同时避开滴答最深的产品护城河？
这两个问题导向的是完全不同的公司。
还有一种很适合 AI Builder 的生意：事件型软件
有些机会根本不值得做成十年公司，但非常值得快速做。
Relay.app 是 2026 年一个很鲜活的例子。
Relay 官方已经宣布关停：免费用户在 8 月 15 日结束，付费用户可以使用到 9 月 14 日。更关键的是，官方允许用户导出 workflow、sequence 和 MCP server 的 JSON 与 AI prompts，同时还能导出 run history 和 table CSV。关停公告几乎把迁移产品需要的输入格式都准备好了。
面对这种事件，最笨的反应是：”那我也做一个 Relay。”
更合理的第一步可能只是：
上传 Relay export，尽可能转换成 n8n 或 Make workflow，再把无法自动迁移的节点列成 checklist。
自动化只能覆盖 70% 也没关系，剩下 30% 可以卖 assisted migration。用户现在要解决的不是”未来十年最完美的 workflow builder 是什么”，而是”我的生产流程下个月别断”。
Microsoft Publisher 正在制造另一种遗产型窗口。
微软官方已经确认，Publisher 会在 2026 年 10 月结束生命周期；Microsoft 365 用户在 10 月 1 日后不能再通过 Publisher 打开和编辑 Publisher 文件。微软自己的建议是提前把 .pub 转成 PDF 或 Word。官方退役说明甚至专门提醒有大量文件的用户做批量转换。
这时一个独立开发者未必应该从”重做完整 Publisher”起步。
更合理的产品阶梯可能是 .pub viewer → 批量 converter → 轻量编辑 → 只有在真实用户不断要求时再扩展复杂桌面出版能力。
事件先给你流量和急迫需求，长期产品再从里面长出来。
与其扫热门软件，不如扫”软件事故”
梳理完这些以后，我越来越觉得应该把机会发现做成一个持续系统，而不是偶尔刷 Product Hunt 等灵感。
我把它暂时叫作 Software Escape Radar。
它不先问”最近什么 App 很火”，而是持续抓这些变化：sunset、shutdown、discontinued、price increase、acquired by、forced migration、feature removed；同时追踪 X alternative、switching from X、X for Android、X for Windows、X is too expensive、X used to be better，甚至 why does X need AI 这类搜索和社区语言。
这些词背后对应的不是抽象趋势，而是用户正在经历的切换事件。
同样值得关注的还有 App Store、Google Play 最近差评里反复出现的同一句抱怨，官方 changelog 里突然删除的能力，支持文档中新出现的迁移指南，以及收购之后用户最担心的变化。
这套雷达最好再加一个”时间衰减”。
一个产品今天宣布关停，接下来几周可能是最强的迁移窗口；半年以后，用户要么已经找到替代品，要么已经放弃原工作流。事件型机会的竞争优势经常不是多写 30 个功能，而是比别人早两周看到，然后足够快地上线。
AI 编程正好让这种打法越来越现实。
我会怎么给一个替代品机会打分
我现在会用一个很粗的启发式公式提醒自己别只看分子：
机会强度 ≈（存量用户 × 不满程度 × 切换触发器 × 可触达性）÷（切换成本 × 实现复杂度 × 原厂反击能力 × IP/平台风险）
它当然不是数学模型，但很好用。
一个有 1000 万用户的软件，看起来市场巨大；如果数据无法导出、网络效应很强、你需要三年才能做到可迁移，它未必比一个只有 10 万重度用户、刚宣布停服、文件格式开放的小工具更适合独立开发者。
我真正动手前，会按这个顺序验证：
- 先证明逃逸存在。 找真实迁移帖、差评、搜索词和官方事件，区分”抱怨”与”正在换”。
- 再证明切口足够窄。 用一句话说清是谁、为什么不再用原版、你的版本只解决什么；如果第一版就需要复制原产品 80% 功能，通常应该继续缩。
- 先消灭最大的技术未知。 比如 Publisher 先拿真实
.pub做保真率测试；Android Assistant 先验证系统入口、锁屏和 OEM 行为，不先做漂亮首页。 - 让用户用行动验证，而不是只点赞。 等待名单、预售、付费迁移服务、导入真实数据、安装测试版，都比”这个想法不错”有价值。
这套顺序的核心是尽量晚写大工程，尽量早碰真实迁移。
现在就能看到的几个现场样本
Publisher 是我目前很喜欢的一类机会。它无聊、历史包袱重、不性感，但用户手里有真实文件，官方退役时间已经确定，而且”以后怎么打开和继续编辑”是一个非常具体的问题。这样的市场很适合先做兼容层，再判断能不能长成完整产品。
Relay 则更像短期事件套利。窗口只有几个月，适合做 converter、migration checker 和人工迁移服务，不适合先花半年造另一个 Zapier。
Things 代表长期平台缺口。Windows 和 Android 用户已经知道自己想要什么，原产品长期坚持 Apple 生态也让缺口足够清楚。但这个项目的风险同样明显：Things 的价值很大一部分来自细节和完成度。谁以为”把功能抄齐”就够了，大概率会重演我从一木清单回到滴答清单的故事。
Google Assistant 向 Gemini 的迁移则是另一种值得观察的信号。Google 在 2026 年 8 月的官方社区公告里确认，9 月 3 日开始在移动设备上移除 Google Assistant，Gemini 会成为 Android 上的语音助手体验。Google 的公告延续了它此前公开的 AI-first 方向。
这会不会给一个”少聊天、低延迟、只把闹钟、电话、智能家居命令可靠执行掉”的 Classic Assistant 留出位置？我觉得值得验证，但现在还不能称为机会已经成立。系统 Assistant 权限、热词唤醒、锁屏、不同 OEM 的限制，以及最关键的用户付费意愿，都需要先做技术 spike 和真实访谈。
这也提醒我：雷达发现的是候选，不是答案。
借需求，不要借品牌和表达
“替代品创业”和低质量山寨之间还有一条很实际的边界。
美国版权局关于 ideas、methods 和 systems 的说明明确指出，在美国版权法框架下，版权不保护 idea、procedure、process、system 或 method of operation 本身，但具体的文字、图像等表达可以受到保护。Circular 31适合用来理解这个基本区分。它当然不意味着功能一样的软件就没有商标、专利或其他法律风险，更不能代替具体法律意见。
平台规则还可能比版权边界更直接。
Apple 的 App Review Guideline 4.1 Copycats明确写着，不要简单复制热门 App，也不要只对别人的名称或 UI 做轻微修改后当成自己的产品；未经许可，也不能在 App 名称或图标里使用其他开发者的 icon、brand 或 product name。
对独立开发者，一个比较实用的原则是：借 Job，借工作流，借已经被验证的需求；代码、视觉、品牌和具体表达自己做。
这样做还有一个商业上的好处。你被迫回答”我到底改变了什么”。如果除了名字和颜色之外说不出答案，这个项目本来也很难形成长期位置。
以后再看到一个成功软件，我不会先问”它能不能仿”。
我会先看它的用户正在被迫接受什么：一个不想付的订阅，一个永远缺席的平台，一个越来越臃肿的产品，一次收购，一项被删除的功能，一堆即将打不开的旧文件，或者一个他们根本不想要的战略方向。
再问三个问题：这些人在主动找替代吗？原厂为什么没有解决？我能不能只接住这一群人，在最小范围里做得明显更合适？
这三个问题有清楚答案以后，才值得写第一行代码。