不写代码也能做出第一版
用现成工具搭出可验证的版本，并知道什么时候必须开始写代码。
不是所有产品都要从零写代码。很多想法用现成工具就能验证完，有些甚至可以一直这么跑下去。
这一页的判断标准只有一条：
这个版本能不能让你拿到真实的行动信号——有人用了、有人付了、有人回来了。
能拿到，用什么搭的都不重要。
什么情况适合用现成工具
- 落地页或展示型网站——用可视化建站工具几天就能做出体面的页面
- 核心逻辑是"表单 + 数据表"——一个在线表格加一个页面生成工具就够了
- 需要一个内部用的管理界面——数据看板、审批流程，用现成工具比写代码快得多
- 只是想验证需求——一个表单加一套自动回复，能模拟很多产品的核心动作
- 移动端原型——可视化 App 构建工具能做出可交互的原型给人看
第四条最被低估。 很多人以为"验证需求"必须先有产品，实际上一个表单加人工交付就能回答最关键的问题。做法见先用人工跑一遍。
工具按能力挑，不按名气挑
不用记产品名，记这几类能力：
| 你要什么 | 找什么类型的工具 |
|---|---|
| 一个好看的静态页面 | 可视化建站 / 设计导出型工具 |
| 表单收集加数据存储 | 在线表格 / 轻量数据库 |
| 把表格数据变成网站 | 数据驱动的页面生成工具 |
| 完整的网页应用含后端逻辑 | 可视化应用搭建平台 |
| 内部管理界面 | 内部工具搭建平台 |
| 把几个服务串起来 | 自动化流程工具 |
选的时候看三件事：有没有免费额度够你验证完、数据能不能导出、涨价历史怎么样。
第二条是硬线。数据导不出来的工具不要用来存真实用户数据——你会被锁死在这个平台上。
什么时候必须开始写代码
出现下面任一情况，就该写代码，或者找一个会写代码的伙伴：
- 业务逻辑复杂——精细的权限、复杂的计算规则、实时同步
- 需要定制的交互——现成组件库有限，做不出你要的体验
- 性能要求高——数据量或并发上来后会明显变慢
- 要接支付和其他第三方接口——很多平台支持，但出问题时排错成本很高
- 平台风险变成实质风险——涨价、关停或改规则会直接影响你的收入
- 需要私有部署或有合规要求——多数平台不支持
第五条是最容易低估的。
产品跑起来之后，你的收入完全建立在一个第三方平台的定价和政策上。它涨价三倍你只能接受，它关停你只能连夜迁移。
判断线很简单：如果这个平台明天关停，你能接受吗？ 不能接受，就该开始把核心部分换成自己的代码。
混合方案通常更实际
"写代码"和"不写代码"不是二选一。更高效的路径是分阶段：
第一阶段：用现成工具搭原型，几天到几周上线测试
第二阶段：有真实用户后，把最核心的模块换成代码
第三阶段：非核心模块继续用现成工具，不急着全部代码化第二阶段先换的通常是这几块：存用户数据的地方、涉及钱的地方、你的核心逻辑。 邮件、表单、静态页面这些可以一直用现成工具。
不需要一开始就把整个系统都代码化。 先验证有人愿意付费，再投入时间写代码，比先花三个月写代码然后发现没人要要明智得多。
用现成工具也要守住的底线
不写代码不等于不用管这些：
| 底线 | 具体做法 |
|---|---|
| 数据能导出 | 定期手动导一份，别只信平台的备份 |
| 用户数据不乱放 | 别把敏感信息填在公开可访问的表格里 |
| 说清楚谁能看到 | 涉及用户材料时，明确告知处理方式 |
| 收款渠道正规 | 不用个人转账收商业款项 |
第一条要真的做过一次。没导出过的数据，等于你不知道能不能导出。
常见错误
用不能导出数据的工具存真实用户数据。 会被平台锁死。
以为"验证需求"必须先有产品。 一个表单加人工交付就够。
收入完全建立在一个平台上还没有 B 计划。 涨价或关停时只能被动接受。
一有用户就急着全部重写。 先换核心模块，其他不急。
把敏感用户信息填在公开可访问的表格里。 这是真实事故的常见来源。
用个人转账收商业款项。 对账和退款都会出问题。
验收标准
- 当前版本能拿到真实行动信号，不只是"看起来能用"
- 用的工具都能导出数据，并且真的导出过一次
- 敏感用户信息没有放在公开可访问的地方
- 知道哪个环节是平台风险最高的，也知道换掉它要多久
- 收款走的是正规渠道
- 能说出什么信号出现后开始写代码
本章动作
写下这句：
如果我依赖的平台明天关停，我需要______天恢复服务，
最先要换掉的是______。天数超过一周的，现在就该准备第二方案。