先设计流程，再考虑附加功能
有效的需求说明应交代应用为谁而做、用户需要完成什么，以及现有办法为什么不顺畅。以此为基础，才能确定必要的页面、数据与连接。
例如，现场工作应用的核心流程可能是打开已分配任务、记录文字与照片、提交完成报告。排班、管理看板和客户消息可以留到后续阶段。这只是范围示例，并非已完成客户项目的案例。
目标是推出真正解决问题的首版，同时把运行所需的依赖讲清楚。
定制 Android 项目可能包含什么？
| 范围 | 需要共同明确的内容 |
|---|---|
| 用户体验 | 核心任务、页面流程、导航、输入校验与无障碍需求。 |
| 账户与权限 | 谁可以登录、有哪些角色、每种角色能访问什么。 |
| 应用数据 | 哪些数据保存在本地、哪些归服务器管理、如何同步更新。 |
| 外部连接 | 所需 API、厂商 SDK、通知或硬件连接。 |
| 设备支持 | 手机与平板要求、Android 版本以及指定设备型号。 |
| 交付 | 测试版本、验收标准、发布责任与交接资料。 |
这些是讨论范围的类别，不表示每个项目都会包含所有功能。后端、管理面板、订阅以及持续托管如有需要，应分别写进项目范围。
Android 是重点时，考虑原生开发
如果用户主要使用 Android，且产品大量依赖平台能力，值得评估 Kotlin 原生方案。新界面可以采用 Jetpack Compose；已有基于 View 的应用通常也能逐步改进，无须一次替换全部页面。
技术选择应服从需求。如果 iOS 同样重要，而且大部分体验可以共享，确定分别开发两套移动应用之前，可先比较 Flutter 开发方案。
若产品需求已经明确，主要需要原生实现，请参阅 Kotlin 与 Jetpack Compose 开发。
别忽略用户会遇到的真实状况
弱网络、上传中断或关闭应用后重新进入，可能直接影响任务能否完成。如果这些场景与产品相关，就应写入需求与测试计划。
离线支持并非打开一个开关。需要决定断网时哪些操作可用、未提交的修改如何显示，以及两人编辑同一条记录时如何处理冲突。仅展示缓存内容与离线录入后同步，复杂度并不一样。
加载中、空数据与出错状态也应区分。“目前没有结果”不应与“服务器无法连接”混为一谈。
从需求沟通到明确的首版范围
需求梳理： 说明用户、核心任务和已有系统，找出会使固定报价不可靠的信息缺口。
技术方案： 确认应用结构、数据流、集成点及目标设备。风险较高的依赖可以先做小规模验证。
开发实施： 按可审查的阶段交付已约定功能。范围变化应公开讨论。
测试与交接： 检查约定的用户流程，记录已知限制，并准备方案中规定的构建与发布资料。
可将应用商店上架支持纳入项目，但开发者账户、商店规则和最终审核结果各有独立责任。
哪些因素会影响报价？
主要因素包括用户流程的数量和复杂度、后端准备程度、接口质量、设备要求与测试范围。完整需求和可用 API 能减少不确定性；未完成的代码或缺乏文档的设备协议则可能增加工作量。
如果预算或目标日期有硬性限制，请直接说明。我们可以讨论精简首版，而不是暗中删减保证可靠性所需的工作。
常见问题
只有想法或粗略设计，也能开始吗？
可以。初次讨论只需说明用户、任务与业务目标。更细致的调研或设计工作会在开始前另行界定。
应用能连接现有网站或业务系统吗？
有可能。需要查看可用 API、身份验证、权限与数据要求。集成专项内容请参阅 API 与 SDK 集成。
Android 应用能离线使用吗？
针对特定功能可以。范围需明确离线可执行的操作、本地数据处理及恢复连接后的同步方式。
定制应用需要 root 权限吗？
普通业务或消费类应用通常不需要。依赖 root 或特权能力的需求应另行评估，不能默认包含在标准项目中。
会交付源码吗？
源码访问、交付物归属、第三方许可和账户责任，都应在开工前写入项目协议，不应依赖含糊的交接承诺。
首版之后可以继续添加功能吗？
可以。后续阶段可以在约定的基础上扩展，但新功能、维护与第三方服务费用应分别界定。
从用户要完成的任务讲起
告诉我们应用必须做什么、目前已有些什么，以及怎样的首版才算真正有用。