企业找APP开发公司时，最常问的是“用什么技术”“做过哪些案例”“多少钱能上线”。这些问题有必要，却不足以判断是否可靠。APP还包含账号、数据、接口、权限、第三方SDK、商店审核、崩溃监控和长期维护，任何一项没有写进范围，都会在后期变成延期、加价或安全风险。
先判断你需要的是纯开发执行，还是从产品梳理、UI/UX、前后端、测试到上架的完整交付团队；再检查10项能力。每项都要求证据，而不是接受“我们都能做”的口头回答。
01 先确认你到底要买什么
合作类型 | 适合情况 | 主要交付 |
|---|---|---|
开发执行型 | 已有明确PRD、设计稿、接口与技术负责人 | 移动端代码、联调、测试和构建 |
设计开发型 | 流程已确定，但需要UI/UX与客户端开发 | 原型、UI、客户端、联调与上线 |
完整产品型 | 需求仍需梳理，涉及后台、数据和运营 | 产品、设计、架构、前后端、测试、部署与维护 |
长期迭代型 | 产品已上线，需要持续版本和质量治理 | 稳定团队、版本计划、监控、数据与SLA |
供应商报价前仍无法说清合作类型，通常意味着后续范围会持续漂移。此时不应急着问固定总价，而应先安排一段付费需求梳理或小范围Discovery。
02 检查1：能不能把业务目标变成可验收范围
优秀团队不会直接把客户提出的所有功能排进开发清单。它会区分用户目标、业务规则、必须上线的核心流程、可以延后的功能和需要验证的高风险假设，最终形成带优先级、边界、状态和验收条件的产品范围。
- 要求查看：需求清单、用户流程、业务规则、异常状态和版本边界。
- 直接追问：如果预算减少30%，第一版保留什么、删除什么，为什么？
- 风险信号：承诺所有功能都能在极短周期完成；没有产品负责人；只按页面数量估价。
03 检查2：提案团队是不是实际交付团队
很多公司展示资深顾问和明星案例，项目开始后却更换为临时拼接团队。合同前应确认产品、设计、客户端、后端、测试和项目管理的具体负责人、投入比例、替换机制与汇报关系。
角色 | 必须承担的责任 |
|---|---|
产品负责人 | 需求、版本、业务规则和验收标准 |
UI/UX设计 | 流程、界面、状态、原型和设计交付 |
客户端开发 | iOS、Android或跨端实现与性能 |
后端/架构 | 接口、数据库、权限、部署与扩展 |
测试/质量 | 测试计划、缺陷管理、兼容与回归 |
项目经理 | 进度、风险、变更、沟通与交付 |
04 检查3：架构和代码能不能被接手
技术栈没有绝对好坏。真正要问的是为什么选择、能否支撑业务、团队是否熟悉、如何测试和部署，以及未来能不能由其他团队接手。NIST的安全软件开发框架强调把安全实践整合进软件开发生命周期，也可作为采购方与供应商沟通的共同语言。
- 代码进入客户可控的Git仓库，不能只在供应商私人账号。
- 提供环境说明、构建脚本、接口文档、数据库说明和部署文档。
- 关键技术决策记录原因、替代方案和后续影响。
- 依赖库、SDK和开源许可证可追踪，并有更新策略。
- 交付前演示从空环境构建、测试并部署，而不只是交压缩包。
05 检查4：安全与隐私是否进入开发流程
安全不是上线前做一次扫描。OWASP MASVS覆盖存储、密码学、认证授权、网络、平台交互、代码质量、抗篡改与隐私。供应商至少应解释哪些数据被收集、存到哪里、谁能访问、保留多久、如何删除。
- 是否做威胁建模和高风险数据清单。
- 登录、权限、支付、文件上传、深链和WebView如何处理。
- 敏感信息是否进入日志、通知、截图、备份或本地明文存储。
- 第三方SDK采集什么数据，是否在同意前运行。
- 漏洞发现、修复、依赖升级和安全事件响应由谁负责。
06 检查5：能否处理商店审核和平台规则
Apple的App Review Guidelines要求应用在安全、性能、商业、设计与法律等方面符合规则，并明确提醒提交前完成测试、元数据和审核访问。供应商不能合法承诺“100%通过审核”，但应提前识别高风险功能，准备演示账号、隐私政策、权限说明和拒审处理流程。
- 上架账号由客户主体持有，供应商使用受控权限协助。
- 商店文案、截图、隐私政策、数据披露和年龄分级是否在范围内。
- 账号创建类应用是否包含账号删除入口。
- 支付、医疗、金融、定位、相机、通讯录等高风险功能是否提前评估。
- 被拒审后的修改轮次、责任和额外费用如何约定。
07 检查6：测试标准是不是只写“无明显Bug”
测试范围应包括功能、接口、异常、兼容、权限、网络、性能、可访问性和回归。稳定性不是上线后的可选优化。
测试类别 | 至少检查 |
|---|---|
功能与业务规则 | 主流程、异常流程、边界条件、重复提交与权限 |
设备与系统兼容 | 目标系统版本、主流设备、横竖屏、字体和语言 |
性能与稳定性 | 启动、渲染、网络、内存、崩溃和卡顿 |
安全与隐私 | 存储、传输、认证、日志、SDK、权限和数据删除 |
可访问性 | 文字缩放、对比度、读屏、焦点和触控区域 |
回归与发布 | 缺陷分级、修复验证、版本记录、灰度和回滚 |
08 检查7：设计是否覆盖真实平台与异常状态
APP设计不能只是把网页缩进手机。评估时要求展示加载、空状态、错误、权限拒绝、离线、弱网、长文本、键盘和系统字体放大后的界面，并说明iOS、Android或跨端方案的取舍。
09 检查8：上线后能不能看见问题
没有监控的APP，只能等待用户投诉。正式范围应说明崩溃监控、日志、关键事件、性能指标、告警、运营数据和版本复盘。供应商需要说明哪些指标由平台提供，哪些由第三方工具采集，数据归谁，谁有权限。
10 检查9：维护、质保和SLA是否明确
项目 | 需要写清 |
|---|---|
质保 | 已确认范围内的功能缺陷与兼容问题；期限和起算点 |
运维 | 服务器、证书、域名、备份、监控和容量 |
版本维护 | 操作系统、商店政策、SDK和依赖升级 |
新增需求 | 新功能、改版、数据迁移和业务规则变化 |
SLA | 故障等级、响应、临时方案、修复和沟通频率 |
11 检查10：退出时能不能完整带走资产
合作终止或更换供应商时，客户应能继续运行产品。退出机制需覆盖代码仓库、设计源文件、构建证书、商店账号、云资源、域名、数据库、接口密钥、第三方服务、文档、缺陷和知识移交。
- 所有生产账号以客户主体注册，并使用最小权限分配给供应商。
- 合同按阶段约定代码、设计、文档和账号的交付时间。
- 尾款前完成一次由客户或第三方执行的独立构建与部署。
- 确认开源许可证、商业SDK、字体、图片和云服务的续费责任。
12 90分钟尽调会议怎么开
时间 | 会议任务 |
|---|---|
0–15分钟 | 让供应商重述业务目标、用户、范围和最大风险 |
15–35分钟 | 让实际产品、设计和技术负责人拆解一个核心流程 |
35–55分钟 | 查看真实项目的版本、代码结构、测试和上线记录 |
55–70分钟 | 讨论安全、隐私、SDK、商店审核与运维责任 |
70–85分钟 | 逐项核对报价、排除项、变更、验收和退出机制 |
85–90分钟 | 要求会后提交未解决问题和风险清单 |
13 100分供应商评分表
评估项 | 权重 |
|---|---|
产品理解与范围定义 | 15 |
实际团队与沟通 | 10 |
架构、代码与文档 | 13 |
安全、隐私与数据 | 12 |
UI/UX与平台适配 | 10 |
测试、性能与质量 | 12 |
商店上架与发布 | 8 |
监控、运维与维护 | 8 |
报价、合同与变更 | 7 |
资产归属与退出机制 | 5 |
建议的一票否决项包括：客户无法控制代码和商店账号；拒绝说明第三方SDK；实际团队无法确认；关键数据没有安全方案；合同中知识产权和退出条件不清。
14 常见问题
应该选原生开发还是跨平台开发？
这不是先选公司的标准。应根据功能、性能、平台能力、团队、维护和预算做技术决策。专业公司应能解释不同方案的取舍。
APP开发周期一般多久？
取决于需求成熟度、端数、后台、接口、测试和审核。只根据页面数量承诺固定周期，通常不可靠。
案例越多的公司越好吗？
不一定。重点核验相似复杂度、实际团队、本人角色、上线维护和可验证结果，而不是案例墙数量。
是否需要第三方代码审查？
涉及高敏感数据、金融、医疗、交易或长期核心系统时值得考虑。普通项目也应安排内部技术负责人或独立顾问做关键节点审查。
结语
选择APP开发公司，本质上是在选择未来一段时间内共同承担产品、技术、数据、上架和运营风险的团队。案例和技术栈只能证明过去做过什么，不能证明它能在你的约束下把项目交付出来。
更可靠的方式，是要求候选公司用同一份需求回答10项问题，并提供可核验的团队、架构、测试、安全、上架和维护证据。无法解释代码归属、数据责任、测试标准和退出机制的低价方案，通常只是把成本推迟到后期。
