APP 开发是把业务闭环做成移动端产品：账户、交易、消息、会员、内容或内部作业流程。我们覆盖 iOS、Android、小程序和 H5，从需求文档、原型、UI 到前后端、管理后台、测试和上线协助。
不是所有业务都值得做 APP。如果用户使用频次低、核心动作在微信里完成，小程序或 H5 往往更合适；如果涉及高频使用、离线能力、设备调用、消息推送或复杂交互，APP 的价值才明显。
我们通常先问三个问题：用户多久用一次？核心动作是什么？需不需要留在手机桌面上？答案不清楚时，先做小程序或 MVP 验证，比直接投入完整 APP 更稳。
一个可上线的 APP 通常不止“一个客户端”。交付清单会在需求阶段拆清楚，常见包括：
路线没有绝对好坏，只有和业务阶段匹不匹配。
| 路线 | 优势 | 限制 | 适合 |
|---|---|---|---|
| 原生 APP | 体验最好，系统能力完整，推送稳定 | 双端成本高，迭代慢 | 高频使用、设备调用多、体验要求高 |
| 跨平台 APP | 一套代码覆盖双端，成本可控 | 重度图形和底层能力仍需原生补 | 交易、内容、工具类 MVP 和成长期产品 |
| 小程序 | 获客路径短，微信内传播方便 | 受平台规则限制，能力边界有限 | 低频服务、门店、活动、预约、轻交易 |
| H5 | 上线快、分发成本低、跨平台 | 体验和留存弱，推送能力有限 | 活动页、表单、轻量工具、内容展示 |
明确用户角色、核心闭环、不做什么。
先确认流程和页面，再进入视觉。
按里程碑交付可安装版本，持续验收。
功能、兼容、异常场景测试，准备上架材料。
监控、修复、按数据规划下一期。
MVP 参考周期为 4–8 周，复杂项目按阶段拆分。最终排期以需求清单和双方确认的计划为准。
看功能边界和体验要求。需要深度调用相机、蓝牙、定位、音视频或高性能图形时，原生更稳；以表单、列表、交易、消息为主，且希望一套代码覆盖 iOS 和 Android 时，Flutter 或 React Native 更划算。我们会先列功能清单再给建议，不默认推最贵的方案。
我们负责准备上架所需的技术材料、隐私说明和测试包，并协助处理审核问题。开发者账号由客户注册并持有，避免账号归属纠纷。应用商店的审核结果和上架时间不受开发者控制。
通常包含。APP 涉及用户、订单、内容或权限时，需要一个后台来运营。后台功能范围在需求阶段明确，避免出现“前端做完了才发现没人管数据”的情况。
源码归属和交付范围在合同中约定。可以约定交付完整源码、数据库结构、接口文档和部署说明；也可以只交付可运行系统。两种模式都会在报价和合同里写清楚。
提供上线后维护期，覆盖缺陷修复和必要的稳定性调整。新功能按迭代排期，单独评估工作量。建议预留每月固定迭代预算，比“攒一年再改”更可控。
费用由角色与权限、核心功能数量、第三方对接、后台复杂度、是否需要上架和运维共同决定。MVP 可以先做核心闭环，再按数据决定下一期，不建议一上来堆满功能。