移动应用
有人跟你说「你们应该做个 App」。可能是同行做了，可能是客户随口提的，也可能是你自己想过——毕竟所有人一天都在看手机。但真正要说清楚这个 App 要解决什么，一时又说不上来。
业务被桌面绑住了。当核心系统已经稳定，把它延伸到现场与客户手上，触点才会真正扩大。
做错载体的代价特别高，因为 App 不像网站——它有两个平台要维护、有审核流程、有版本更新，而且最关键的是：你得说服人去下载它。一个每年只用两次的 App，没有人会留在手机里。多数「应该做个 App」的需求，其实用一个手机上好用的网站就解决了，成本差好几倍。
根本原因是把「手机上能用」和「需要一个 App」当成同一件事。手机浏览器已经能做绝大部分事情：下单、预约、查资料、付款、推播通知也行。真正需要原生 App 的理由只有几个——要用到相机、GPS、离线作业、蓝牙设备，或者使用频率高到值得占一个桌面图标。不属于这几种，网站更省、更快、也更容易被找到。
工作是怎么进行的
先确认手机是不是对的载体
谁在用、在哪里用、多久用一次、用的时候手上还拿着什么。现场作业的人跟坐在办公室的人，需要的东西完全不同。这一步的结论有时候是「你需要的是把网站做好手机版」。
只做真正要用的功能
第一版应该小到有点不安。App 的功能一多，下载后的第一分钟就会劝退人。先做一件事、做到好用，再看资料决定加什么。
跟你已经在跑的系统接上
App 不该是第五份资料。它读的、写的应该是你既有系统里的同一笔——否则你只是把「资料存在四个地方」的问题，变成了存在五个地方。
把上架与更新算进成本
两个平台的开发者账号、审核时间、系统版本更新之后的兼容性维护——这些不是意外，是 App 的固定成本。开发前就该讲清楚，而不是上线之后才发现。
业务会变成什么样
- 一个诚实的载体判断
- App、手机网站、还是两者都不需要——给出结论和理由。这一条对我们来说经常是把生意做小的答案。
- 现场作业真的用得上
- 如果是给外勤、司机、技师用的，那就要能在讯号不好的地方用、能单手操作、按钮够大。这些不是细节，是会不会被用的分界。
- 跟既有资料同一份
- App 里看到的和后台看到的是同一笔。不会出现「手机上显示还有货，仓库说没有」这种事。
- 上架与后续更新有人管
- 上架流程、审核回覆、之后的系统版本兼容——可以交给我们持续处理，而不是交付后你自己面对两家平台。
包含什么
- 移动应用开发
- 客户入口 App
- 现场作业 App
- 系统整合让 App、网站与核心系统共用同一份资料
持续支持
持续支持：版本发布、系统更新兼容与真实使用反馈的迭代。
这一项单独报价
网站配套有公开起价，因为范围够清楚。这一项没有，因为范围差距太大——给一个中间值，对小项目是吓阻，对大项目是空头支票。会先做一次免费诊断把范围谈清楚，再报价。
看网站配套的公开起价，以及为什么这一项没有什么情况下现在还不该做这个
现在不该做的：为了「有一个 App」而做 App。如果核心系统本身还在变，App 只会跟着一起变。
常见问题
- 网站和 App，我该做哪个？
- 多数情况是网站。判断方法很简单：如果你的用户一个月用不到几次，他不会为你留一个图标；如果需要相机、GPS、离线、蓝牙设备，或者是给每天要用十次的内部同事用，那 App 才有理由。我们会照这个标准判断，包括得出「不需要 App」的时候。
- iOS 和 Android 都要做吗？
- 看你的用户在用什么。给内部团队用的通常一个平台就够，因为设备是你自己配的；给一般消费者用的两个都要，不然你等于放弃一半市场。我们用能同时输出两个平台的技术做，但「能做」和「值得做」是两件事，会分开评估。
- 上架会不会被拒？
- 会，而且很常见——通常是隐私说明、账号删除、支付方式这几类问题。做法是在开发阶段就照两家平台的规则设计，而不是提交之后再改。这一段的时间要算进排程里，不该假设一次就过。
- 做完之后还要一直花钱吗？
- 有，这一点跟网站不同，值得先想清楚。开发者账号是年费，系统每年更新一次、旧写法会失效，需要跟着维护。所以我们会建议：如果你不打算长期维护它，那就不要做 App——一个两年没更新、在新系统上打不开的 App，比没有 App 更伤形象。