「独立开发」听起来浪漫，但真做起来是一串很具体的事。这篇不讲心法，只把这个流程按顺序拆开，让你知道每一步大概要做什么、一个人做时该在哪省、哪不能省。
第 0 步：先想清楚「做给谁用」
这是我见过最多人跳过、也最不该跳过的一步。判断标准可以很朴素：
能不能用一句话说清它是给谁解决什么问题；
这个问题你自己会不会真的遇到（自己会用，才撑得住长期打磨）；
有没有一个「不做也能忍」的替代方案（如果有，说明需求没你想的那么痛）。
第 1 步：需求收敛，写到能被砍
独立开发者最大的敌人是「功能太多」。我的做法是先列出所有想做的，然后强制砍到只剩「第一版不做就不能用」的部分。
一条实用的判断：如果一个功能删掉之后，App 依然能解决那个核心问题，它就属于第二版。
第 2 步：设计 —— 一个人怎么做界面
我不会做视觉设计，所以我的做法是「结构优先」：
先把页面画成线框：有哪几块、每块放什么信息、主操作在哪；
用系统提供的标准控件和排版规则，不自创风格；
界面的一致性比好看更重要：同样的操作，永远在同样的位置、同样的反馈。
一个很实在的经验：用系统原生控件和规范，能让界面在没设计师的情况下也不难看。花在「发明新交互」上的时间，通常不如花在「把主流程做顺」。
第 3 步：开发 —— 先跑通，再做好
我习惯把开发分成两轮：
第一轮「跑通」：数据结构、核心流程、能点到最后一屏。这一轮界面可以很丑；
第二轮「做好」：补状态（加载中/失败/空数据）、补边界、补体验细节。
为什么强调「先跑通」：因为独立开发最危险的不是做得慢，而是做到一半失去信心。先拿到一个「能用」的版本，后面所有改进都有依据。
第 4 步：测试 —— 一个人怎么测
没有测试团队，就得靠方法补。我用的几招：
自己当「最没耐心的用户」：不看说明直接点，看会不会迷路；
专门测三个状态：没网、第一次用（没有任何数据）、中途退出再进来；
找几个真人用，但只听「哪一步卡住了」，不听「建议加什么功能」。
第 5 步：上架 —— 比想象中琐碎
上架是流程性最强的部分，也是第一次做最容易翻车的地方：
证书与描述文件先配好，这是后面一切的基础；
商店信息要准备好：截图、描述、关键词、隐私说明，这些都有规范要求；
审核被拒很常见，通常不是因为功能，而是因为描述不清、权限说明不足、或触碰了某条规则。
关于被拒，我的心态建议是：把审核意见当成一份「免费的产品说明文档」。它常常能指出你自己没意识到的表述问题。
第 6 步：上架不是终点
真正的工作从上架后才开始：看崩溃、看反馈、看数据，然后决定先改哪一个。我给自己定的节奏是：小步快跑，每次只改一两个地方，不要攒一个「大版本」再发。
一个人做，哪些能省、哪些不能省
这张表是我自己的取舍经验：
能省：视觉设计（用系统规范顶）、动画（第一版可以少）、后台管理界面（能用即可）；
不能省：数据结构（改起来最贵）、核心流程的流畅度、错误与空状态的处理（这决定了「像成品还是像半成品」）。
给准备一个人做 App 的人三点建议
先做一个「一周内能看到样子」的小东西，不要一上来就做平台级产品；
把「上架流程」当成一次学习任务，走通一遍之后就不再怕；
把「保持能持续做」当成硬要求 —— 能做完比做得多好更重要。
这套流程我后来又用它做了别的项目。它真正有价值的地方不在「App」，而在于它是一种「把想法落成一个能交付的东西」的通用办法。