“要拍照上传，所以必须做原生 APP”还不足以确定方案。采购时需要说明的是拍什么、在什么设备和网络下完成、失败后怎样继续，以及用户从哪里进入服务。功能名称本身没有交代这些条件。
先写出首期需要验证的一次业务操作
例如现场人员拍照后提交一条巡检记录。先确认照片是否必须断网保存、是否连接特定设备、何时算提交成功，以及用户退出后是否需要接着处理。这里是需求讨论示例，不是已完成客户项目或性能测试。
如果首期只是验证客户愿不愿意提交咨询，复杂离线能力可能暂时不属于范围；如果断网工作是现场不可回避的条件，就需要把它放进方案验证。不能因为叫“MVP”就把实际使用所必需的步骤删掉。
产品入口和实现技术要分开决定
用户是否愿意安装、如何再次找到服务、所需能力是否能在目标平台提供，决定产品入口。选择 APP 之后，仍需比较原生与跨端实现。React Native 平台差异文档说明了共用代码中保留分平台实现的方式；采用跨端框架也需要处理系统差异，不能将其理解为所有平台无需单独维护。
对候选方案做小样时，要求开发者演示那次完整业务操作，记录设备、系统版本、权限状态和网络条件。拍照、上传或消息等词只说明需求方向，实际可行性要以目标平台的当前能力和测试结果确认。进一步比较实现方案，可参考设备能力与维护预算的选型讨论。
“先做轻量版”也要算后续迁移的工作
首期方案需要写清账号、业务数据和接口由谁维护，哪些部分下一阶段能继续使用，哪些需要重新开发。若后续入口改变会导致用户重新注册或历史记录无法衔接，应当在首期决策中说明，而不是把“以后升级”当成无成本承诺。
讨论两种方案时，用同一条业务路径和相同验收条件比较。开发工作、账号与平台准备、发布测试及后续维护分别列出，才能看到差异；没有这些前提，不能断言轻量版一定更便宜或更快。
发布条件也是首期范围的一部分
计划进入 App Store 时，Apple 审核指南要求提交前确认功能可测试、资料准确，并在审核期间提供可用的后台服务；涉及账号功能时需要相应的演示访问条件。完成页面或打包不能代替这些准备，也不意味着审核一定通过。
在方案确认记录中保留三项结果：首期入口、尚未验证的能力、重新评估的触发条件。例如小样不能满足约定的断网恢复行为，就回到方案比较；仅仅增加几个页面，不必自动推导为更换技术路线。触发条件来自项目需要，由客户与开发共同确认。